आम समस्याएं:
- समूह द्वारा व्यवहार। PostgreSQL का एक सख्त GROUP BY है। यदि आप ग्रुप बाय क्लॉज का उपयोग करते हैं, तो आपके चयन में प्रत्येक कॉलम या तो आपके ग्रुप बाय में दिखाई देना चाहिए या समग्र फ़ंक्शन में उपयोग किया जाना चाहिए।
- डेटा कटौती। MySQL चुपचाप एक
char(n). के अंदर फ़िट होने के लिए एक लंबी स्ट्रिंग को काट देगा कॉलम जब तक आपका सर्वर सख्त मोड में नहीं है, PostgreSQL शिकायत करेगा और आपको अपनी स्ट्रिंग को स्वयं ही छोटा कर देगा। - उद्धरण अलग है, MySQL पहचानकर्ताओं को उद्धृत करने के लिए बैकटिक्स का उपयोग करता है जबकि PostgreSQL दोहरे उद्धरण चिह्नों का उपयोग करता है।
- LIKE MySQL में केस असंवेदनशील है लेकिन PostgreSQL में नहीं। यह कई MySQL उपयोगकर्ताओं को LIKE को केस असंवेदनशील स्ट्रिंग समानता ऑपरेटर के रूप में उपयोग करने के लिए प्रेरित करता है।
(1) यदि आप AR के group . का उपयोग करते हैं तो एक समस्या होगी किसी भी कच्चे एसक्यूएल में आपके किसी भी प्रश्न या ग्रुप बाय में विधि। क्या column "X" must appear in the GROUP BY clause or be used in an aggregate function और आपको कुछ उदाहरण और सामान्य समाधान दिखाई देंगे।
(2) यदि आप अपने आवेदन में कहीं भी स्ट्रिंग कॉलम का उपयोग करते हैं और आपके मॉडल सभी की लंबाई को ठीक से मान्य नहीं कर रहे हैं तो यह एक समस्या होगी। आने वाली स्ट्रिंग मान। ध्यान दें कि एक सीमा निर्दिष्ट किए बिना रेल में एक स्ट्रिंग कॉलम बनाना वास्तव में एक varchar(255) बनाता है कॉलम इसलिए वास्तव में एक निहित :limit => 255 है भले ही आपने एक निर्दिष्ट नहीं किया हो। एक विकल्प t.text . का उपयोग करना है t.string . के बजाय आपके स्ट्रिंग्स के लिए; यह आपको दंड के बिना मनमाने ढंग से बड़े तारों के साथ काम करने देगा (कम से कम PostgreSQL के लिए)। जैसा कि इरविन नीचे नोट करता है (और उसे मिलने वाला हर दूसरा मौका), varchar(n) PostgreSQL दुनिया में एक कालानुक्रमिकता का एक सा है।
(3) तब तक कोई समस्या नहीं होनी चाहिए जब तक कि आपके कोड में रॉ SQL न हो।
(4) यदि आप अपने आवेदन में कहीं भी LIKE का उपयोग कर रहे हैं तो यह एक समस्या होगी। आप a like b . को बदलकर इसे ठीक कर सकते हैं से lower(a) like lower(b) (या upper(a) like upper(b) अगर आप चिल्लाना पसंद करते हैं) या a ilike b लेकिन ध्यान रखें कि PostgreSQL's ILIKE
गैर-मानक है।
ऐसे और भी अंतर हैं जो परेशानी का कारण बन सकते हैं लेकिन वे सबसे आम मुद्दों की तरह लगते हैं।
सुरक्षित महसूस करने के लिए आपको कुछ चीजों की समीक्षा करनी होगी:
groupकॉल.- कच्चा SQL (
whereमें किसी भी स्निपेट सहित) कॉल)। - आपके मॉडलों में स्ट्रिंग लंबाई सत्यापन।
- LIKE के सभी उपयोग।
