पीडीओ (PHP डेटा ऑब्जेक्ट्स) के बारे में अब तक जो कुछ भी मैंने पढ़ा है, वह सच होने के लिए लगभग बहुत अच्छा है।पीडीओ के नुकसान (PHP डेटा ऑब्जेक्ट्स)
मेरा मतलब है:
लेकिन पीडीओ के नुकसान क्या हैं?
पीडीओ (PHP डेटा ऑब्जेक्ट्स) के बारे में अब तक जो कुछ भी मैंने पढ़ा है, वह सच होने के लिए लगभग बहुत अच्छा है।
मैं हर दिन पीडीओ का उपयोग करता हूं, और यह एक कारण के लिए है। हालांकि मैंने इसके ऊपर एक रैपर लिखा था, क्योंकि डिफ़ॉल्ट पीडीओ इंस्टेंस ऐसी चीजें करता है जो मुझे पसंद नहीं है (उदा। चुपचाप विफल), और एपीआई पूरी तरह से बेहतर हो सकता था। स्थिरांक के साथ विन्यास सिर्फ मेरा डिफ़ॉल्ट दृष्टिकोण नहीं है। इसके अलावा, मैंने कुछ सुविधा विधियां बनाई हैं।
इसकी तेज़ी से mysql या mysqli।
क्या यह है? मुझे नहीं पता कि आपने इसे कहाँ चुना है, और यह सच भी हो सकता है, लेकिन मैंने पीडीओ को मूल माईएसQL पुस्तकालयों से तेज़ नहीं सुना है।
यह कई डेटाबेस चालकों के लिए एक ही वाक्य रचना है।
क्रमबद्ध करें। मैं PostgreSQL का बहुत उपयोग करता हूं, और जब आप MySQL के साथ काम कर रहे होते हैं तो कोड अलग होता है। हालांकि यह समझ में आता है, क्योंकि PostgreSQL नामित अनुक्रमों के साथ काम करता है, जबकि MySQL "ऑटो वृद्धि" के साथ काम करता है, जो प्रति तालिका अनुक्रम है। डेटाबेस के बीच मतभेद हैं जो पीडीओ अमूर्त नहीं हो सकता है, भले ही यह डेटाबेस एक्सेस तक पहुंच जाए।
तैयार बयान के साथ यह एसक्यूएल इंजेक्शन के लिए सुरक्षित है।
आप prepare statements with mysqli भी कर सकते हैं, इसलिए मुझे इसे एक निश्चित उछाल के रूप में नहीं देखा जाता है। मैं आम तौर पर तैयार कथन का उपयोग करता हूं, और मुझे यह पसंद है: फ़ील्ड सिंटैक्स पीडीओ प्रदान करता है।
लेकिन पीडीओ के नुकसान कहां हैं, ऐसे में कुछ पेशेवरों के पास कुछ भी होना चाहिए।
एपीआई मेरे लिए अंतर्ज्ञानी से कम है, मुझे लगता है कि mysqli का एपीआई अधिक समझ में आता है। फिर भी, यदि आप स्वयं के लिए एक रैपर लिखते हैं, तो यह एक बहुत सभ्य पुस्तकालय है। यहां पीडीओ का उपयोग करने के लिए the wrapper I wrote है, हालांकि इंटरनेट पर कई और उदाहरण बहते हैं।
संपादित करें: ओह, और जेम्स एंडरसन सही है; इसमें ओरेकल समर्थन खराब है। मैं ओरेकल का उपयोग नहीं करता, इसलिए मुझे यह नहीं लगता कि यह एक विशाल नकारात्मक है।
पीडीओ एक तैयार कथन के लिए mysql सर्वर पर कम डेटा भेजने की आवश्यकता होने के बाद कई बार तैयार कथन का उपयोग करते समय mysql_ * से तेज हो सकता है, हालांकि कई तैयार वक्तव्य करते समय और कुछ बार निष्पादित करते समय यह तेज़ नहीं होता है और यह निश्चित रूप से नहीं है Mysqli से तेज़। – Mike
मेरी दृष्टि में पीडीओ ** में mysql * से तेज हो सकता है ** ** किसी भी सभ्य डीबी पृष्ठभूमि के साथ लंगड़ा प्रोग्रामर के लिए कठिन/अनुमति नहीं दे रहा है, लेकिन एक ठोस ओओ एक **, डीबी 26 बार पूछताछ करने के लिए केवल एक के बजाय बुरे प्रश्नों के साथ * दाएं * क्वेरी के साथ। – ZJR
^इस बार एक लाख। – mopsyd
मुझे कहीं पढ़ना याद है कि पीडीओ के नुकसान में से एक यह है कि इसमें कुछ और पूछताछ का समय लगता है। (क्षमा करें मुझे उस लेख का संदर्भ नहीं है), उम्मीद है कि कुछ विशेषज्ञ इसके बारे में बता सकते हैं।
दो कमियां है कि मैं के बारे में पता:
नहीं या गरीब Oracle समर्थन!
बड़े प्रदर्शन सेट पर कुछ प्रदर्शन हिट।
जहां तक मुझे लगता है कि पहले "डाउनसाइड" ओरेकल से बचने का एक और कारण है। दूसरा शायद ही कभी मायने रखता है।
बाइंड तंत्र स्तंभ या तालिका नामों के साथ काम नहीं करता है।
सरल उदाहरण:
CREATE TABLE :bar (rowId int)
SELECT :foo FROM :bar
उज्जवल पक्ष पर, यह कुछ आप अक्सर की जरूरत है या करना चाहते हैं नहीं है।
लेकिन जब आप करते हैं ... पीडीओ आपको लटका देता है। समाधान मैन्युअल रूप से एक साथ अपने क्वेरी स्ट्रिंग concating है, जबकि भागने से हाथ कर रही:
$foo = some_escape_logic($dirtyFoo);
$bar = some_escape_logic($dirtyBar);
$db->query("SELECT {$foo} FROM {$bar}");
एसक्यूएल परिणाम हमेशा तार
लाने (के रूप में वापस) स्ट्रिंग मूल्यों की एक सरणी देता है, यहां तक कि एसक्यूएल तालिका अगर प्रकार संख्यात्मक हैं। उदाहरण के लिए, bigint/स्ट्रिंग/bigint कॉलम युक्त तालिका देता है:
array('rowId' => '1', 'name' => 'Fred', 'age' => '12');
:
array('rowId' => 1, 'name' => 'Fred', 'age' => 12);
एक सकारात्मक रूप में, आप PHP और एसक्यूएल प्रकार के बीच एक बेमेल से परिशुद्धता कभी न खोएं। PHP में टाइप जॉगलिंग यह भी सुनिश्चित करता है कि आप शायद ही कभी ध्यान दें कि डेटा मूल रूप से तारों के रूप में एन्कोड किया गया था।
एक नकारात्मक रूप में, यह एक दर्द जब json_encode (की तरह कुछ करने के लिए डीबी परिणाम गुजर) हो सकता है, जब से तुम उद्धृत संख्यात्मक मान के साथ खत्म हो जाएगा:
{ "rowId": "1", "name": "Fred", "age": "12" }
{ "rowId": 1, "name": "Fred", "age": 12 }
एक आदर्श दुनिया में, fetch() से स्वत: कास्टिंग आउटपुट प्रकार वैकल्पिक तर्क के माध्यम से नियंत्रित किया जाएगा।
मुझे कुछ समय पहले उद्धृत पहली समस्या मिली। जब मैंने पर्याप्त सीखा कि मैं डेटाबेस रिलेशनशिप योजना गलत कर रहा था तो बाहर निकला। मैंने इसे ठीक किया और कभी भी इस समस्या को कभी नहीं मिला। वैसे भी +1 –
एसक्यूएल परिणाम हमेशा तारों के रूप में लौटते हैं - mysql ड्राइवर के साथ मामला लगता है, लेकिन पोस्टग्रेसर ड्राइवर नहीं। यदि आप पीडीओ के साथ पोस्टग्रेस का उपयोग कर रहे हैं तो यह मूल्यों को निकटतम समकक्ष PHP प्रकार पर मैप करने का प्रयास करेगा – GordonM
इसकी तेज़ी से mysql या mysqli।
गलत। वास्तविक जीवन में यह सामान्य रूप से धीमा है।
यह कई डेटाबेस चालकों के लिए एक ही वाक्य रचना है।
एपीआई कार्यों के लिए - हां, ज़ाहिर है। लेकिन यह आपको विभिन्न एसक्यूएल बोलियों के साथ मदद नहीं करेगा।
तैयार बयान के साथ यह एसक्यूएल इंजेक्शन के लिए सुरक्षित है।
, एसक्यूएल इंजेक्शन के खिलाफ सुरक्षित करने की चार मामलों सही तरीके से छोड़े जाने वाले की जरूरत है:
जबकि पीडीओ केवल firs कवर टी दो।
PHP के साथ हमेशा की तरह ही बात: प्रकार असुरक्षित मतलब है कि डेवलपर अनुशासित नहीं है। बग शिकार नरक। सामान्य। – bdares
@bdares यह वास्तव में सुंदर प्रकार सुरक्षित है, और आपका तर्क पीडीओ के खिलाफ नहीं, PHP और इसकी प्रकृति के खिलाफ है। –
मुझे नहीं पता कि सभी डेटाबेस के लिए एक ही वाक्यविन्यास से आपका क्या मतलब है। यदि आपका मतलब एसक्यूएल है, तो आप गलत हैं। पीडीओ डेटा-एक्सेस एब्स्ट्रक्शन लेयर है और डेटाबेस एब्स्ट्रक्शन नहीं है, एसक्यूएल अलग रहता है। यदि आप प्रश्न बनाने में मतलब रखते हैं, तो आप सही हो सकते हैं, लेकिन एक साधारण रैपर लिखना आपको एक ही चीज़ प्रदान करता है यदि आप डेटाबेस प्रकार को बदलना चाहते हैं। – frostymarvelous