क्या अजगर

Question

के लिए व्यवहार्य डेटाबेस अमूर्त परतों मैं एक ओपन सोर्स प्रोजेक्ट Gramps जो एक संबंधपरक डेटाबेस के लिए BSDDB से अपने बैकएंड स्विचिंग पता लगा रहा है में शामिल होने के शुरू कर रहे हैं। या तो SQLite या MySQL हमने पूरी तरह से निर्णय नहीं लिया है और कुछ सीमित क्षमता में दोनों को करने का भी प्रयास कर सकते हैं। मैं एक पेशेवर डेवलपर हूं लेकिन मैं अजगर के लिए नया हूं इसलिए मैं उपकरण/पुस्तकालयों के वर्तमान चयन से परिचित नहीं हूं। मुझे डीबी एब्स्ट्रक्शन परतों के शोध के साथ काम सौंपा गया है। There is currently a wiki discussion going on to compare them. एक ऑब्जेक्ट रिलेशनल मैपर अच्छा हो सकता है लेकिन बिल्कुल जरूरी नहीं है। हालांकि मुझे पता है कि आमतौर पर डीबी एब्स्ट्रक्शन लेयर का पर्याय बन जाता है। यदि एक ओआरएम शामिल है तो विज्ञापन हॉक प्रश्नों को बिना कुश्ती के उपलब्ध होना चाहिए।

अभी सूची में शामिल हैं:

CouchDB मैं अभी तक इस में नहीं देखा है।

DB-API यह एक मानक पायथन एपीआई लगता है और प्रत्येक डीबी अपना स्वयं का मॉड्यूल बनाता है जो इसका उपयोग करता है। यहां तक ​​कि बीएसडीडीबी में भी एक लिखा है लेकिन मैंने पूरी तरह से इसका पता नहीं लगाया है। मॉड्यूल विनिमेय हैं?

SQLAlchemy यह अभी सबसे लोकप्रिय लगता है? लेकिन मेरे पास अजगर की दुनिया में बहुत सीमित जोखिम है।

SQLObject मैंने अभी तक इस में ध्यान नहीं दिया है।

तो लोगों विचार और अजगर के लिए डेटाबेस अमूर्त परतों पर सुझाव क्या हैं?

Answer 1

SQLAlchemy पर बहुत बारीकी से देखो।

आप SQLite के साथ परीक्षण और विकास कर सकते हैं।

आप MySQL के साथ उत्पादन में जाना जा सकता है - अनिवार्य रूप से आपके आवेदन करने के लिए कोई बदलाव नहीं बना रही है।

डीबी-एपीआई, व्यापक रूप से पालन करने के दौरान, पर्याप्त लचीलापन है कि (1) आप अंतर्निहित आरडीबीएमएस में एसक्यूएल विविधता से इन्सुलेट नहीं हैं और (2) अभी भी डीबी ड्राइवर-विशिष्ट विशेषताएं हैं जो कठिन हैं छिपाना।

एक और अच्छा ORM परत ORM कि Django का हिस्सा है है। आप (थोड़ी सी कोशिश के साथ) Django वेब ढांचे का उपयोग किए बिना केवल Django ORM का उपयोग कर सकते हैं।

डीबी एपीआई वरीयता में एक ORM लेयर (SQLAlchemy या SQLObject) का प्रयोग करें।

क्यों? आपका मॉडल एक ठोस, स्पष्ट, अच्छी तरह से सोचा ओओ मॉडल होना चाहिए। ऑब्जेक्ट मॉडल के बाद संबंधपरक मैपिंग दूसरा आना चाहिए। SQLAlchemy यह एक उचित दृष्टिकोण बनाता है।

ए 'डीबी अमूर्त परत "घटनाओं के सामान्य कोर्स में क्या होगा। दरअसल, डीबी-एपीआई (जैसा कि एसक्लाक्लेमी द्वारा उपयोग किया जाता है) के कारण आपने दो अमूर्त परतें दी: ओआरएम और डीबी-एपीआई।

Answer 2

पायथन से उचित डेटाबेस तक पहुंचने से लगभग हमेशा डीबी-एपीआई 2.0-अनुरूप एडाप्टर मॉड्यूल का उपयोग किया जाता है। जबकि सभी डीबी-एपीआई मॉड्यूल में समान एपीआई (या बहुत समान हैं; सभी बैकएंड सभी सुविधाओं का समर्थन नहीं करते हैं), यदि आप स्वयं एसक्यूएल लिख रहे हैं, तो आप शायद उत्पाद-विशिष्ट बोली में SQL लिख रहे होंगे, इसलिए वे इनके रूप में अदला-बदले नहीं हैं अभ्यास के रूप में वे सिद्धांत में हैं।

ईमानदारी से, SQLite आपके उपयोग के मामले के लिए बिल्कुल सही लगता है।मैं "एम्बेडेड MySQL" से परेशान नहीं होगा; यह दोनों दुनिया के सबसे बुरे की तरह लगता है। चाहे आप एक ओआरएम चाहते हैं जैसे स्क्लाक्लेमी पूरी तरह से आपके ऊपर है; किसी भी तरह से अच्छे तर्क हैं। व्यक्तिगत रूप से, मैं ओआरएम को नापसंद करता हूं, लेकिन फिर मेरे पास गणित की डिग्री है, इसलिए तथ्य यह है कि मैं एसक्यूएल की भाषा के रूप में सराहना करता हूं शायद यह आश्चर्यजनक नहीं है :)

Answer 3

कॉच डीबी एक रिलेशनल डेटाबेस नहीं है, इसलिए इसमें कोई संबंध नहीं है डीबी-एपीआई इंटरफ़ेस। यह एक दस्तावेज़ डेटाबेस है जिसका अर्थ है कि यह ग्रैंप के लिए उतना उपयोगी नहीं होगा क्योंकि संबंधित लोगों के बीच संबंधों की पहचान करने के लिए कुछ बदलावों की आवश्यकता होगी। इसके शीर्ष पर यह केवल क्लाइंट/सर्वर मोड में चलाया जा सकता है।

SQLAlchemy, SQLObject, या Django ORM की तरह किसी भी ORM डीबी एपीआई के शीर्ष पर लागू किया जाता है और मैं इन प्रत्यक्ष डीबी एपीआई से अधिक के किसी भी उपयोग करने की अनुशंसा क्योंकि यह दादाजी स्थानीय के लिए एम्बेडेड मोड में SQLite चलाने का लचीलापन दे सकते हैं डेस्कटॉप उपयोगकर्ता और फिर ग्राम के वेब आधारित संस्करण के साथ, सड़क के नीचे कभी भी एक पोस्टग्रेस्क्ल/MySQL डेटाबेस कनेक्शन साझा करते हैं।

Answer 4

मैं वास्तव में Storm चाहते:

तूफान एक वस्तु-संबंधपरक नक्शाकार (ORM) के लिए पाइथन विहित में विकसित है। परियोजना विकास में इस तरह के रूप लॉन्चपैड विहित परियोजनाओं में उपयोग के लिए एक वर्ष से अधिक के लिए किया गया है, और हाल ही में एक खुला स्रोत उत्पाद के रूप में जारी किया गया है।

मेरी राय में, तूफान SQLAlchemy से सीखना बहुत आसान है। Django के ओआरएम के समान है।

Answer 5

अपनी परियोजना कभी भी किसी भी वास्तविक जटिलता होगा, तो ORMs से दूर रहना।

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

Answer 6

जब मैं एक ORM मैं SQLObject और SQLAlchemy में देखा उपयोग करने के लिए लेगेसी एप्लिकेशन को परिवर्तित करने शुरू कर दिया। सबसे पहले मैं SQLObject के साथ गया क्योंकि यह परिचित (पिछले Django अनुभव) देखा और SQLAlchemy जटिल लग रहा था। लगभग 2 घंटे बाद मैंने SQLObject के साथ दीवारों को हिट करना शुरू कर दिया। फिर मैंने स्क्लेक्लेमी को फिर से देखा और तुरंत पुरस्कृत किया गया। न केवल डेटाबेस में हर अजीब तालिका को समझता और मैप करता है, यह भी बाद में पहनने वाले लुकअप लुकअप भी कर सकता था!

Answer 7

मुझे लगता है कि CouchDB दादाजी के रूप में ऐसी परियोजना के लिए सबसे अच्छा विकल्प होगा। दादाजी के लिए

उपयोगी CouchDB विशेषताएं:

• कोई स्कीमा, कोई माइग्रेशन। http://www.freedesktop.org/wiki/Specifications/desktopcouch

:

• , सीधे डेटाबेस के लिए फ़ाइलों को संग्रहीत करने उदाहरण परिवार फोटो, आदि .: http://guide.couchdb.org/draft/api.html#attachments

• उबंटू डेस्कटॉप सोफे के माध्यम से CouchDB का समर्थन करता है और यह आसानी से साझा करने या backuping के लिए Ubuntu एक साथ एकीकृत है के लिए के लिए समर्थन

• आप आसानी से CouchDB डेटाबेस को दोहराने कर सकते हैं ... उन्हें एक बड़ा डेटाबेस, आदि में शामिल होने,

• CouchDB बहुत लचीला है।

Answer 8

वेब 2py में डेटाबेस एब्स्ट्रक्शन लेयर है जिसका उपयोग स्टैंडअलोन तरीके से किया जा सकता है।हमने SQL कोड 3, माइक्रोसॉफ्ट एसक्यूएल सर्वर, ओरेकल और MySQL के बीच शून्य कोड परिवर्तन के साथ स्विच किया। प्रभावित किया।