दोनों ने कथन तैयार किए हैं। pg_ * libpq के लिए एक रैपर है। सही?पीडीओ बनाम पीजी_ * फ़ंक्शंस
मैं PHP में पीडीओ पसंद है, लेकिन मैं भविष्य में डेटाबेस को बदलने के लिए नहीं जा रहा हूँ। मुझे किस लाइब्रेरी का उपयोग करना चाहिए? कोई बेंचमार्क? PHP संस्करण: 5.4
IMHO कार्यों कि सीधे ठोस डीबी दृष्टिकोण का उपयोग कर (जैसे pg_, oci_, mysql[i]_ आदि) हमेशा एक छोटा सा जल्दी एक पीडीओ या किसी डीबीएमएस परत (सिद्धांत, Dibi, आदि) का उपयोग कर तो है ।
लेकिन ओओपी आर्किटेक्चर में पीडीओ या किसी भी डीबीएमएस परत का उपयोग करना बेहतर दृष्टिकोण होना चाहिए (आईएमएचओ, दोबारा), क्योंकि आप इस परत का उपयोग करना सीखते हैं और इस प्रकार इसका उपयोग डीबी इंजन के पीछे भी किया जाएगा। बेशक यदि आप ऐप के भीतर डीबी इंजन बदलते हैं तो आपको पूरे ऐप के पुनर्लेखन से परेशान नहीं होना पड़ेगा।
यहां तक कि अगर आप डीबी इंजन मैं पीडीओ का उपयोग करने की अनुशंसा करेंगे बदलने के लिए योजना नहीं बना रहे। लेकिन सिर्फ मेरी राय thats :-)
मुझे लगता है कि यह अधिक स्वाद की बात है। PDO संकलित होने के बाद तेज़ हो सकता है, या ऐसा नहीं हो सकता है क्योंकि यह एक रैपर के रूप में कार्य करता है। मुझे यकीन है कि गति अंतर आपके निर्णय पर असर न करने के लिए पर्याप्त छोटा होगा।
यह शुद्ध अटकलें है, लेकिन PDO नया है और अब डीबी कनेक्शन के लिए मानक हो रहा है, तो कोड के मामले में इसके लिए समर्थन शायद बढ़ेगा, जबकि mysql_* के लिए समर्थन और शायद pg_* पतन के लिए जारी रहेगा।
PDO का प्रमुख लाभ यह है कि इसके अमूर्तता से आप बाद में एक अलग डीबी पर स्विच कर सकते हैं, लेकिन मुझे लगता है कि आप नहीं करेंगे, इसलिए शायद आपके निर्णय को भी नहीं रोकना चाहिए।
मैं व्यक्तिगत रूप से PDO के साथ काम करना पसंद करते हैं। "संसाधन" चर से वस्तुओं को पास करना और नियंत्रित करना आसान है।
विस्फोट, क्या आप निश्चित हैं? मैं PHP और पोस्टग्रे के साथ नया हूं और अब तक मुझे यह तय करने की ज़रूरत है कि मैं किस तकनीक का उपयोग करूंगा, मैं कुछ परीक्षण चला रहा था और पीजीओकनेक्ट पीडीओ की तुलना में अधिक तेज़ प्रतीत होता है। – HMarioD
पीडीओ एक अच्छा इंटरफ़ेस, लेकिन अधिक genericity भी प्रत्येक बैकएंड के सूक्ष्म idiosyncrasies के साथ निपटने के लिए और अधिक परेशानी का मतलब है प्रदान करता है। यदि आप the bugtracker देखते हैं, तो इसमें कई खुले मुद्दे हैं, और उनमें से कुछ गंभीर हैं।
पोस्टग्रेस्क्ल के साथ यहां एक अचूक सबूत है: पीडीओ के पार्सर को मानक_कॉन्फोर्मिंग_स्ट्रिंग्स को चालू करने के लिए परेशानी है (जो अब डिफ़ॉल्ट है, पीजी-9.1 के रूप में)। php-5.3.9 के साथ टेस्ट मामला:
$dbh->exec("SET standard_conforming_strings=on");
$p=$dbh->prepare("SELECT 1 WHERE 'ab\' = :foo AND 'cd' = :bar");
$p->execute(array(":foo" => "ab", ":bar" => "cd"));
निष्पादित() अप्रत्याशित रूप से Database error: SQLSTATE[HY093]: Invalid parameter number: :foo साथ पीडीओ परत में विफल रहता है। ऐसा लगता है कि यह पहचानने में असमर्थ है: पैरामीटर के रूप में foo।
यदि क्वेरी 'ab\'=:foo के बाद बंद हो जाती है, तो बिना किसी शर्त के, यह ठीक काम करता है। या यदि अन्य स्थिति में स्ट्रिंग शामिल नहीं है, तो यह भी ठीक काम करता है।
समस्या issue #55335 के समान दिखती है, जिसे के रूप में खारिज कर दिया गया था, मेरी राय में काफी गलत नहीं है। [वास्तव में, मैंने इसे ठीक करने के लिए पीडीओ को भी हैक किया है, लेकिन इस तरह से अन्य बैकएंड के साथ असंगत है, इसलिए कोई पैच नहीं है। मैं क्वेरी जेक्सिकल विश्लेषक इतने सामान्य होने से विघटित था।]
दूसरी तरफ, pg_ * libpq के करीब होने के कारण, इस तरह की समस्या पहले स्थान पर होने की संभावना कम होती है, और अगर यह हल हो जाती है तो हल करना आसान होता है।
तो मेरा मुद्दा यह होगा कि पीडीओ के साथ सब कुछ अच्छा नहीं है। आंतरिक रूप से, यह निश्चित रूप से pg_ * से अधिक चुनौतीपूर्ण है, और अधिक जटिलता का अर्थ अधिक बग है। क्या ये बग संबोधित हैं? कुछ बगट्रैक प्रविष्टियों के आधार पर, जरूरी नहीं।
+1 उत्कृष्ट पोस्ट। प्रासंगिक सबूत के साथ प्रमाणित, अपने बिंदु बहुत स्पष्ट बना दिया। आरडीबीएमएस के करीब रहना तेज और साफ है। –
@MorrisonHotel मुझे माफ़ कर दो? – shadyyx
मेरी टिप्पणी खराब है, आप नहीं :) – MorrisonHotel
पोस्टग्रेएसक्यूएल: ** चुनें I_TING (...) mytable LIMIT 1 ऑफ़सेट 1 ** MySQL: ** SELECT DATE_FORMAT (...) mytable LIMIT से 1,1 ** जैसा कि हम देखते हैं, यहां तक कि पीडीओ का उपयोग करके, मुझे डेटाबेस में सभी अनुरोधों को फिर से लिखना होगा। तो, पीडीओ एक पैनसिया नहीं है। मुझे सिद्धांत, प्रोपेल इत्यादि का उपयोग करना होगा (बाहर रखा गया है)। – MorrisonHotel