MySQL और PostgreSQL दोनों SQL का उपयोग करते हैं, लेकिन वे हमेशा इसे एक ही तरह से व्याख्यायित नहीं करते।
MySQL में बिल्कुल सामान्य दिखने वाली क्वेरी PostgreSQL में ले जाने के बाद विफल हो सकती है या अलग तरह से व्यवहार कर सकती है।
माइग्रेशन के दौरान जाँचने योग्य सात अंतर यहाँ दिए गए हैं।
1. आइडेंटिफ़ायर को उद्धृत करना
MySQL में टेबल और कॉलम नामों के चारों ओर आमतौर पर बैकटिक का उपयोग किया जाता है:
SELECT `name`, `order`
FROM `customers`;
PostgreSQL में उद्धृत आइडेंटिफ़ायर के लिए डबल कोट का उपयोग किया जाता है:
SELECT "name", "order"
FROM "customers";
जब किसी आइडेंटिफ़ायर में स्पेस, बड़े अक्षर या आरक्षित शब्द हों, तब उद्धरण विशेष रूप से महत्वपूर्ण हो जाता है।
दीर्घकाल में बेहतर तरीका यह है कि जहाँ संभव हो, ऐसे सरल लोअरकेस आइडेंटिफ़ायर उपयोग किए जाएँ जिनके लिए उद्धरण की आवश्यकता न हो।
2. अपने-आप जनरेट होने वाली IDs
MySQL की टेबल AUTO_INCREMENT का उपयोग कर सकती है:
CREATE TABLE customers (
id INT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(100)
);
आधुनिक PostgreSQL समकक्ष में identity कॉलम का उपयोग किया जा सकता है:
CREATE TABLE customers (
id INTEGER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
name VARCHAR(100)
);
PostgreSQL SERIAL का भी समर्थन करता है, लेकिन नई स्कीमा के लिए identity कॉलम अधिक स्पष्ट, मानक-आधारित व्यवहार प्रदान करते हैं।
डेटा माइग्रेट करने के बाद जाँचें कि PostgreSQL sequence, आयात की गई सबसे बड़ी ID के बाद भी जारी है।
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 इसी ऑपरेशन को interval के साथ व्यक्त कर सकता है:
SELECT order_date + INTERVAL '7 days'
FROM orders;
दिखाई देने वाला सिंटैक्स इस अंतर का केवल एक हिस्सा है।
जब एप्लिकेशन के लिए महत्वपूर्ण हो, तब तारीख के प्रकार, timestamps, time zones, महीने की सीमाओं और daylight-saving व्यवहार की भी जाँच करें।
6. स्ट्रिंग को जोड़ना
MySQL में आमतौर पर CONCAT का उपयोग किया जाता है:
SELECT CONCAT(first_name, ' ', last_name)
FROM customers;
PostgreSQL CONCAT का समर्थन करता है, लेकिन इसमें आमतौर पर double-pipe ऑपरेटर का भी उपयोग किया जाता है:
SELECT first_name || ' ' || last_name
FROM customers;
जब मान NULL हो सकते हों, तब सावधान रहें। इनपुट के आधार पर अलग-अलग concatenation विधियाँ अलग परिणाम दे सकती हैं।
नाम, पते, रिपोर्ट लेबल और कई कॉलमों को मिलाने वाली अन्य अभिव्यक्तियों का परीक्षण करें।
7. Upsert सिंटैक्स
MySQL ON DUPLICATE KEY UPDATE के साथ किसी पंक्ति को insert या 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 स्टेटमेंट conflict target की स्पष्ट पहचान करता है।
Upsert बदलने से पहले unique constraints और indexes की समीक्षा करें, क्योंकि यही तय करते हैं कि PostgreSQL किन conflicts का पता लगा सकता है।
और क्या परीक्षण किया जाना चाहिए?
सिंटैक्स रूपांतरण केवल पहला चरण है।
MySQL की क्वेरी या स्कीमा को बदलने के बाद, प्रतिनिधि डेटा का उपयोग करके स्रोत और लक्ष्य के व्यवहार की तुलना करें।
जाँचें:
• पंक्तियों की संख्या
• NULL मान
• जनरेटेड IDs
• तारीख और समय के परिणाम
• दशमलव की सटीकता
• अक्षर-रूप के प्रति संवेदनशीलता
• क्रमबद्ध करने का क्रम
• डुप्लिकेट को संभालना
• डिफ़ॉल्ट मान
सफलतापूर्वक चलने वाला SQL अपने-आप सही व्यवहार करने वाला SQL नहीं होता।
एक भरोसेमंद माइग्रेशन वर्कफ़्लो
एक व्यावहारिक MySQL-to-PostgreSQL वर्कफ़्लो इस प्रकार है:
स्रोत SQL को समझें
इसे PostgreSQL में बदलें
डायलेक्ट-विशिष्ट बदलावों की समीक्षा करें
डायग्नोस्टिक्स देखें
प्रतिनिधि डेटा के साथ परीक्षण करें
परिणामों की तुलना करें
सत्यापन के बाद ही डिप्लॉय करें
Sqlinfy, MySQL और PostgreSQL के बीच संरचित प्रारंभिक रूपांतरण तैयार करने में मदद कर सकता है। उत्पादन में उपयोग करने से पहले डेवलपर्स को परिवर्तित SQL की समीक्षा और परीक्षण फिर भी करना चाहिए।
