2013-02-20 12 views
6

उदाहरण परिदृश्य:क्यों django और python MySQLdb प्रति डेटाबेस एक कर्सर है?

MySQL एक एकल सर्वर चल रहा -> HOSTNAME

दो MySQL कि सर्वर पर डेटाबेस -> उपयोगकर्ता, खेल।

कार्य - (मान नहीं मिलती है)

Django के साथ-साथ अजगर MySQLdb में, क्यों प्रत्येक के लिए एक कर्सर रहा है USERS.my_users_table से उन खेल खेल> GAMES.my_games_table से 10 नवीनतम खेल लायें, और लाने के उपयोगकर्ताओं डेटाबेस अधिक बेहतर है?

क्या एक विस्तारित कर्सर का नुकसान जो MySQL सर्वर प्रति एकल है और डेटाबेस ("उपयोग करने वाले उपयोगकर्ताओं," पूछताछ की जैसे) स्विच कर सकते हैं, और फिर इसी डेटाबेस

MySQL कनेक्शन सस्ते पर काम करते हैं, लेकिन प्रतिसाद नहीं यदि कोई रैखिक प्रवाह होता है और कोई जटिल ट्रान्ससाक्शन नहीं होता है जिसके लिए दो कर्सर की आवश्यकता हो सकती है, तो कई से बेहतर कनेक्शन नहीं है?

+0

Django एकाधिक डेटाबेस कनेक्शन का समर्थन करता है - https://docs.djangoproject.com/en/dev/topics/db/multi-db/ –

+0

@ जोनाथन वांस्को हाँ, यह बिल्कुल मेरा सवाल है, 2 के लिए दो कनेक्शन क्यों होना चाहिए समान सर्वर पर स्थित डेटाबेस। उदाहरण के लिए। settings.py में मुझे दोनों उपयोगकर्ता और गेम को परिभाषित करना होगा, और django एक के बजाय 2 कनेक्शन बनाएगा। – DhruvPathak

+2

@ dm03514 यह एक उदाहरण परिदृश्य है। तार्किक shards मानें, या कुछ अन्य डेटाबेस के केवल दास पढ़ें। नीचे पंक्ति है, एकल mysql उदाहरण पर एकाधिक डेटाबेस। – DhruvPathak

उत्तर

9

एक छोटा जवाब होगा, "MySQL उस प्रकार के कर्सर का समर्थन नहीं करता है", इसलिए न तो पाइथन-माईएसक्यूएल करता है, इसलिए कारण एक कनेक्शन कमांड को प्राथमिकता दी जाती है क्योंकि यही तरीका है MySQL काम करता है। जो एक प्रकार का टौटोलॉजी है।

हालांकि, अब जवाब है:

  1. ए 'कर्सर', अपने परिभाषा से, वस्तु के कुछ प्रकार एक RDMS भीतर टेबल्स और सूचियों को एक्सेस करते समय, अपनी स्थिति को बनाए रखने में सक्षम होगा।
  2. आपकी परिभाषा से एक 'कनेक्शन', आदेश स्वीकार करेगा, या कमांड की कार्रवाई करने के लिए कर्सर आवंटित या पुन: उपयोग करेगा, इसके परिणामों को कनेक्शन में वापस कर देगा।
  3. आपकी परिभाषा के अनुसार, एक 'कनेक्शन' एकाधिक कर्सर प्रबंधित/प्रबंधित कर सकता है।
  4. आपको विश्वास है कि डेटाबेस तक पहुंचने के लिए यह पसंदीदा/सक्षम तरीका होगा क्योंकि 'कनेक्शन' महंगे हैं, और 'कर्सर' सस्ते हैं।

हालांकि:

  1. MySQL (और अन्य RDMS) में एक cursor ऑपरेशनों को करने के लिए एक उपयोगकर्ता के सुलभ तंत्र नहीं मानता। MySQL (और अन्य) संचालन को "सेट" के रूप में निष्पादित करते हैं, या इसके बजाय, वे आपके SQL कमांड को कमांड की आंतरिक सूची में संकलित करते हैं, और आपके SQL कमांड और आपकी तालिका संरचना की प्रकृति के आधार पर कई जटिल जटिल बिट्स करते हैं।
  2. cursor एक विशिष्ट तंत्र है, जो संग्रहीत प्रक्रियाओं (और वहां केवल) के भीतर उपयोग किया जाता है, जिससे डेवलपर को प्रक्रियात्मक तरीके से डेटा के साथ काम करने का एक तरीका मिलता है।
  3. MySQL में एक 'कनेक्शन' वह है जिसे आप 'कर्सर' के रूप में सोचते हैं। MySQL आपके लिए इंटरेक्टर या पॉइंटर के रूप में आपके आंतरिक रूप से खुलासा नहीं करता है, जो केवल टेबल पर आगे बढ़ रहा है। यह अपने आंतरिक को 'कनेक्शन' के रूप में उजागर करता है जो SQL और अन्य आदेश स्वीकार करता है, उन आदेशों को आंतरिक क्रिया में अनुवाद करता है, उस क्रिया को निष्पादित करता है, और इसका परिणाम आपको देता है।
  4. यह 'सेट' और 'प्रक्रियात्मक' निष्पादन शैली के बीच अलग है (जो वास्तव में आपके नियंत्रण की ग्रैन्युलरिटी के बारे में है, उपयोगकर्ता को, आरडीएमएस सार तत्वों में अंतर्निहित ग्रैन्युलरिटी तक पहुंच प्रदान की जाती है अपने आंतरिक को दूर करें जब यह उन्हें एपीआई के माध्यम से उजागर करता है)।
2

जैसा कि आप कहते हैं, MySQL कनेक्शन सस्ते हैं, इसलिए आपके मामले के लिए, मुझे यकीन नहीं है कि कोड संगठन और प्रवाह के बाहर तकनीकी लाभ भी है। एसक्यूएल 'यूएसई' बयानों को दर्दनाक रूप से ट्रैक करके एक कर्सर वर्तमान में किस डेटाबेस से बात कर रहा है, इसका ट्रैक रखने के लिए दो कर्सर को प्रबंधित करना आसान हो सकता है। अन्य डेटाबेस के साथ माइलेज भिन्न हो सकता है - याद रखें कि Django डेटाबेस-अज्ञेयवादी होने का प्रयास करता है।

इसके अलावा, उस मामले पर विचार करें जहां दो अलग-अलग डेटाबेस, एक ही सर्वर पर भी, विभिन्न एक्सेस प्रमाण-पत्रों की आवश्यकता होती है। ऐसे मामले में, दो कनेक्शन आवश्यक होंगे, ताकि प्रत्येक कनेक्शन सफलतापूर्वक प्रमाणित हो सके।

0

प्रति डेटाबेस एक कर्सर आवश्यक रूप से बेहतर नहीं है, यह केवल डिफ़ॉल्ट व्यवहार है।

तर्क यह है कि अलग-अलग डेटाबेस अलग-अलग सर्वरों पर नहीं होते हैं, विभिन्न इंजनों का उपयोग करते हैं, और/या विभिन्न प्रारंभिक विकल्पों की आवश्यकता होती है। (अन्यथा, आप पहले स्थान पर विभिन्न "डेटाबेस" का उपयोग क्यों कर रहे हैं?)

अपने मामले में, यदि आपके दो डेटाबेस केवल टेबल के नामस्थान हैं (जिसे SQL शब्दकोष में "स्कीमा" कहा जाना चाहिए) लेकिन रहते हैं वही MySQL उदाहरण, फिर हर तरह से एक कनेक्शन का उपयोग करें। (Django को ऐसा करने के लिए कॉन्फ़िगर कैसे करें वास्तव में एक पूरी तरह से अलग सवाल है।)

आप यह भी सही हैं कि एक कनेक्शन दो से बेहतर है, यदि आपके पास केवल एक धागा है और वास्तव में दो डेटाबेस श्रमिकों की आवश्यकता नहीं है उसी समय।

संबंधित मुद्दे