محتوای آموزشی وبلاگ نت‌آرام
در حال انتقال دیتابیس هستید و پیام
Cannot add or update a child row: a foreign key constraint fails همراه شماره 1452 ظاهر می‌شود. به زبان ساده، یک رکورد می‌خواهد به رکورد دیگری اشاره کند که در جدول مرجع پیدا نشده است؛ پایگاه داده برای جلوگیری از رابطه ناسازگار، نوشتن آن را رد می‌کند.این خطا می‌تواند به ترتیب واردسازی جدول‌ها، ناقص‌بودن بکاپ، انتخاب اشتباه دیتابیس یا تفاوت داده‌ها مربوط باشد. پاک‌کردن محدودیت یا خاموش‌کردن بررسی کلید خارجی شاید پیام را موقتاً پنهان کند، اما داده نامعتبر را درست نمی‌کند. اول باید بفهمیم کدام رابطه و کدام داده مشکل دارد.
کلید خارجی با یک مثال ساده
فرض کنید جدول
customers فهرست مشتریان و جدول orders فهرست سفارش‌هاست. ستون orders.customer_id به شناسه مشتری در customers.id اشاره می‌کند. اگر سفارشی برای مشتری شماره ۱۲ وارد شود اما مشتری ۱۲ در جدول والد نباشد، محدودیت می‌تواند عملیات را با خطای ۱۴۵۲ رد کند.نام این جدول‌ها فقط مثال است و ساختار همه فروشگاه‌ها چنین نیست. بعضی رابطه‌ها چند ستون دارند یا مقادیر خالی را با قواعد خاص می‌پذیرند. در دیتابیس واقعی، نام جدول و ستون را از پیام خطا و تعریف همان محدودیت بردارید. راهنمای MySQL درباره Foreign Key این رابطه‌ها را توضیح می‌دهد.
پیش از عیب‌یابی، مقصد و بکاپ را امن نگه دارید
از فایل اصلی بکاپ و وضعیت فعلی دیتابیس مقصد نسخه امن داشته باشید. ترجیحاً آزمایش را روی یک دیتابیس خالی و جدا انجام دهید، نه روی پایگاه داده‌ای که سایت فعال در حال استفاده از آن است. Import ناموفق می‌تواند بخشی از داده‌ها را قبلاً وارد کرده باشد؛ همه تغییرها لزوماً خودکار به عقب برنمی‌گردند.
اگر فروشگاه فعال است، تاریخ بکاپ و سفارش‌هایی را که بعد از آن ثبت شده‌اند در برنامه انتقال نگه دارید. برگرداندن دیتابیس قدیمی روی سایت اصلی بدون تطبیق سفارش‌های تازه می‌تواند آن‌ها را از نسخه فعال حذف کند.
قدم اول: نام رابطه را از پیام خطا بردارید
متن کامل خطا را بخوانید. معمولاً نام دیتابیس، جدول فرزند، نام محدودیت و جدول یا ستون مرجع در پیام یا جزئیات نزدیک آن دیده می‌شود. اگر فایل Import شماره خط دارد، آن را هم یادداشت کنید. داده‌های شخصی و نام‌های حساس را پیش از ارسال گزارش حذف کنید.
اگر به phpMyAdmin دسترسی دارید، دیتابیس آزمایشی را از ستون کناری انتخاب کنید و در تب SQL، با جایگزینی نام واقعی جدول فرزند، این پرس‌وجو را اجرا کنید:
کد / دستورSHOW CREATE TABLE orders;
این دستور تعریف جدول را نشان می‌دهد و داده‌ای را تغییر نمی‌دهد. در خروجی دنبال
FOREIGN KEY و REFERENCES بگردید. برای مثال، عبارت FOREIGN KEY (customer_id) REFERENCES customers (id) می‌گوید کدام ستون فرزند باید با کدام ستون والد سازگار باشد. اگر جدول هنوز ساخته نشده یا اجازه دیدن تعریف آن را ندارید، تعریف جدول را در بکاپ یا از مدیر دیتابیس بگیرید.قدم دوم: آیا جدول والد و داده موردنیاز وارد شده‌اند؟
در مقصد آزمایشی، وجود جدول والد و تعداد تقریبی داده‌های آن را با منبع یا گزارش بکاپ مقایسه کنید. اگر والد هنوز وارد نشده و فرزند زودتر اجرا شده، لازم است ترتیب و روش انتقال را اصلاح کنید. اگر والد وارد شده ولی شناسه مشخصی غایب است، ممکن است بکاپ ناقص باشد، داده‌ها از دو زمان متفاوت گرفته شده باشند یا شناسه‌ها در مقصد تغییر کرده باشند.
برای یک رابطه ساده مانند مثال مشتری و سفارش، یک پرس‌وجوی فقط‌خواندنی می‌تواند چند رکورد فرزند بدون والد متناظر را نشان دهد:
کد / دستورSELECT o.id, o.customer_id
FROM orders AS o
LEFT JOIN customers AS c ON c.id = o.customer_id
WHERE o.customer_id IS NOT NULL AND c.id IS NULL
LIMIT 20;
قبل از اجرا، نام جدول‌ها و ستون‌ها را مطابق ساختار واقعی تغییر دهید. این نمونه فقط برای رابطه تک‌ستونی است؛ برای کلید چندستونی یا قواعد متفاوت باید شرط دقیق رابطه ساخته شود. خروجی دارای شناسه‌هایی است که والد متناظرشان در همین مقصد پیدا نشده است. خروجی خالی، سلامت همه داده‌ها یا نبود مشکل در فایل واردنشده را ثابت نمی‌کند.
روی دیتابیس بزرگ و فعال، چنین اتصال و جست‌وجویی ممکن است منابع مصرف کند؛ اول روی نسخه آزمایشی و با هماهنگی مدیر اجرا کنید. داده‌های مشتری را در گزارش عمومی قرار ندهید.
راه‌حل را بر اساس علت انتخاب کنید
اگر ترتیب Import اشتباه است: یک مقصد آزمایشی تمیز آماده کنید و انتقال را طبق وابستگی‌ها انجام دهید؛ داده‌های والد باید در زمان نیاز فرزند موجود باشند. فایل‌های چندبخشی را بدون شناخت وابستگی‌ها از وسط اجرا نکنید. اگر محدودیت‌ها چرخه‌ای یا چندمرحله‌ای‌اند، مدیر دیتابیس باید برنامه خاص همان ساختار را مشخص کند.
اگر بکاپ ناقص است: از منبع معتبر نسخه‌ای سازگار و مربوط به یک زمان مشخص تهیه کنید. صرف ساخت یک ردیف ساختگی با شناسه غایب، رابطه ظاهری را درست می‌کند اما ممکن است سفارش را به مشتری اشتباه وصل کند. اطلاعات اصلی را از منبع قابل اعتماد بازیابی و تطبیق دهید.
اگر مقصد یا نام جدول اشتباه است: نام دیتابیس انتخاب‌شده و دستورهای
USE یا نام‌های صریح داخل بکاپ را با مقصد واقعی مقایسه کنید. راهنمای خطای دسترسی ۱۰۴۴ و نام دیتابیس نشان می‌دهد چرا انتخاب مقصد در پنل همیشه همه دستورهای فایل را عوض نمی‌کند.اگر داده‌ها از دو زمان متفاوت‌اند: قبل از ادغام، دامنه زمانی و تغییرات بین دو نسخه را بررسی کنید. در فروشگاه، سفارش، مشتری، پرداخت و موجودی ممکن است به هم وابسته باشند. ترکیب تصادفی دو بکاپ می‌تواند تناقض تازه بسازد؛ ابتدا برنامه تطبیق را در نسخه آزمایشی اجرا کنید.
چرا خاموش‌کردن بررسی کلید خارجی راه‌حل عمومی نیست؟
برخی دستورها بررسی محدودیت را در سطح نشست یا سرور خاموش می‌کنند. این کار در مهاجرت‌های طراحی‌شده کاربردهای خاص دارد، اما اگر داده نامعتبر وارد شود، روشن‌کردن دوباره بررسی الزاماً رکوردهای قبلی را دوباره کنترل نمی‌کند. مستندات MySQL صراحتاً این نکته را برای
foreign_key_checks توضیح می‌دهد.بنابراین برای عبور از خطای ۱۴۵۲، آن را به‌صورت سراسری خاموش نکنید و محدودیت را از جدول حذف نکنید. اگر مدیر دیتابیس در یک مهاجرت خاص به روش متفاوتی نیاز دارد، باید حوزه تغییر، اعتبارسنجی تک‌تک رابطه‌ها و برنامه بازگشت را از قبل طراحی کند.
پس از اصلاح، چه چیزی را تأیید کنیم؟
Import را در مقصد آزمایشی از وضعیت شناخته‌شده تکرار کنید و پیام پایان و خطاهای احتمالی را بخوانید. سپس رابطه‌های مهم، تعداد و نمونه داده‌ها را با منبع مقایسه کنید. در سایت آزمایشی ورود، نمایش محصول یا نوشته و عملیات مرتبط را بدون اتصال به درگاه واقعی بررسی کنید. شمار جدول‌ها به‌تنهایی صحت داده‌ها را ثابت نمی‌کند.
اگر همه آزمون‌ها درست بود، انتقال نهایی را با برنامه قطع یا همگام‌سازی داده‌های تازه انجام دهید و بکاپ قبلی را نگه دارید. برای مشاهده امکانات میزبانی سایت، صفحه هاست وردپرس نت‌آرام را ببینید؛ خطای رابطه داده با تغییر منابع به‌تنهایی رفع نمی‌شود.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام