يستخدم كل من MySQL وPostgreSQL لغة SQL، لكنهما لا يفسرانها دائمًا بالطريقة نفسها.
قد يبدو الاستعلام طبيعيًا تمامًا في MySQL، لكنه يفشل أو يتصرف بشكل مختلف بعد نقله إلى PostgreSQL.
إليك سبعة اختلافات تستحق التحقق منها أثناء الترحيل.
1. اقتباس المعرّفات
يستخدم MySQL عادةً العلامات العكسية حول أسماء الجداول والأعمدة:
SELECT `name`, `order`
FROM `customers`;
يستخدم PostgreSQL علامات الاقتباس المزدوجة للمعرّفات المقتبسة:
SELECT "name", "order"
FROM "customers";
يصبح الاقتباس مهمًا بشكل خاص عندما يحتوي المعرّف على مسافات أو أحرف كبيرة أو كلمات محجوزة.
يتمثل النهج الأفضل على المدى الطويل في استخدام معرّفات بسيطة بأحرف صغيرة لا تتطلب الاقتباس كلما أمكن ذلك.
2. المعرّفات المُنشأة تلقائيًا
قد يستخدم جدول MySQL الخيار AUTO_INCREMENT:
CREATE TABLE customers (
id INT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(100)
);
يمكن لنظير حديث في PostgreSQL استخدام عمود هوية:
CREATE TABLE customers (
id INTEGER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
name VARCHAR(100)
);
يدعم PostgreSQL أيضًا SERIAL، لكن أعمدة الهوية توفر سلوكًا أوضح قائمًا على المعايير للمخططات الجديدة.
بعد ترحيل البيانات، تحقق من أن تسلسل PostgreSQL يستمر بعد أعلى معرّف مستورد.
3. القيم المنطقية
غالبًا ما تمثل تطبيقات MySQL القيم المنطقية باستخدام TINYINT:
CREATE TABLE users (
is_active TINYINT(1)
);
يحتوي PostgreSQL على نوع BOOLEAN مخصص:
CREATE TABLE users (
is_active BOOLEAN
);
قد تحتاج القيم مثل 1 و0 إلى التحويل إلى TRUE وFALSE.
يمكن أن يؤثر هذا الاختلاف أيضًا في تعليمات التطبيق البرمجية والمرشحات والقيم الافتراضية والبيانات المستوردة.
4. التعامل مع قيم NULL
يوفر MySQL الدالة IFNULL:
SELECT IFNULL(phone_number, 'Not provided')
FROM customers;
يستخدم PostgreSQL عادةً الدالة COALESCE:
SELECT COALESCE(phone_number, 'Not provided')
FROM customers;
تدعم كلتا قاعدتي البيانات COALESCE، ويمكن أن يسهل ذلك عمليات الترحيل المستقبلية.
مع ذلك، ينبغي اختبار سلوك NULL بعناية في المقارنات والربط والحسابات والتعبيرات الشرطية.
5. العمليات الحسابية على التواريخ
يمكن لـ MySQL إضافة سبعة أيام باستخدام DATE_ADD:
SELECT DATE_ADD(order_date, INTERVAL 7 DAY)
FROM orders;
يمكن لـ PostgreSQL التعبير عن العملية نفسها باستخدام فاصل زمني:
SELECT order_date + INTERVAL '7 days'
FROM orders;
لا تمثل الصياغة الظاهرة سوى جزء من الاختلاف.
تحقق أيضًا من أنواع التواريخ والطوابع الزمنية والمناطق الزمنية وحدود الأشهر وسلوك التوقيت الصيفي عندما تكون مهمة للتطبيق.
6. ربط السلاسل النصية
يستخدم MySQL عادةً الدالة CONCAT:
SELECT CONCAT(first_name, ' ', last_name)
FROM customers;
يدعم PostgreSQL الدالة CONCAT، لكنه يستخدم أيضًا عامل الأنبوب المزدوج عادةً:
SELECT first_name || ' ' || last_name
FROM customers;
كن حذرًا عندما تكون القيم قابلة لأن تكون NULL. فقد تنتج طرق الربط المختلفة نتائج مختلفة بناءً على المدخلات.
اختبر الأسماء والعناوين وتسميات التقارير والتعبيرات الأخرى التي تجمع بين عدة أعمدة.
7. صياغة upsert
يمكن لـ MySQL إدراج صف أو تحديثه باستخدام ON DUPLICATE KEY UPDATE:
INSERT INTO products (id, name, price)
VALUES (10, 'Keyboard', 49.99)
ON DUPLICATE KEY UPDATE
name = VALUES(name),
price = VALUES(price);
يستخدم PostgreSQL ON CONFLICT:
INSERT INTO products (id, name, price)
VALUES (10, 'Keyboard', 49.99)
ON CONFLICT (id) DO UPDATE SET
name = EXCLUDED.name,
price = EXCLUDED.price;
يحدد بيان PostgreSQL هدف التعارض بشكل صريح.
راجع القيود والفهارس الفريدة قبل تحويل عمليات upsert، لأنها تحدد التعارضات التي يمكن لـ PostgreSQL اكتشافها.
ما الذي ينبغي اختباره أيضًا؟
لا يمثل تحويل الصياغة سوى الخطوة الأولى.
بعد تحويل استعلام أو مخطط MySQL، قارن سلوك المصدر والهدف باستخدام بيانات تمثيلية.
تحقق من:
• أعداد الصفوف
• قيم NULL
• المعرّفات المُنشأة
• نتائج التاريخ والوقت
• دقة الكسور العشرية
• حساسية حالة الأحرف
• ترتيب الفرز
• التعامل مع التكرارات
• القيم الافتراضية
إن نجاح تشغيل SQL لا يعني تلقائيًا أن SQL يتصرف بشكل صحيح.
سير عمل موثوق للترحيل
يتمثل سير العمل العملي للترحيل من MySQL إلى PostgreSQL في:
فهم SQL المصدر
تحويله إلى PostgreSQL
مراجعة التغييرات الخاصة باللهجة
فحص التشخيصات
الاختبار باستخدام بيانات تمثيلية
مقارنة النتائج
النشر بعد التحقق فقط
يمكن أن يساعد Sqlinfy في إنشاء تحويل أولي منظم بين MySQL وPostgreSQL. ومع ذلك، ينبغي للمطورين مراجعة SQL المحوّل واختباره قبل استخدامه في بيئة الإنتاج.
