बेस्ट प्रैक्टिस: डेटाबेस ऐप प्रोग्रामिंग पैटर्न


11

मैंने अब तक कई डेटाबेस (MySQL) वेब ऐप्स लिखे हैं लेकिन मुझे हमेशा लगता है कि मेरी संरचना थोड़े अनाड़ी है। मैं यहाँ प्रोग्रामिंग / डिज़ाइन पैटर्न का उपयोग करना चाहता हूँ, यहाँ कुछ सलाह की उम्मीद है। विशेष रूप से, मुझे एक संरचना नहीं मिल सकती है जो एक OOP दृष्टिकोण को पूरक करता है जो डेटाबेस (स्कीमा) के कार्यान्वयन को बाधित करता है। मैं

लगता है कि मेरे प्रश्न को उदाहरण द्वारा समझाया जा सकता है। 2 दृष्टिकोण हैं जिनका मैं अब उपयोग करता हूं मेरे पास एक इनवॉइस ऑब्जेक्ट / वर्ग है:

पहले स्थैतिक सदस्य कार्यों का उपयोग करना है

class Invoice
{
   int id;
   string ref;
   int customer_id;
   date created;
   date due;

   static id create();
   static bool update(id, field1, field2, ...);
   static bool delete(id);
   static bool get(id);
};

दूसरी बात यह है कि हर वस्तु को डेटाबेस ऑब्जेक्ट में रखा जाए:

class Database extends ProprietaryDBConnecter, Singleton
{
   id createInvoice();
   bool updateInvoice(id, field1, field2, ...);
   bool deleteInvoice(id);
   bool getInvoice(id);

   id createCustomer();
   bool updateCustomer(id, field1, field2, ...);
   bool deleteCustomer(id);
   bool getCustomer(id);

   // etc...
}

मुझे लगता है कि दोनों तरीके (SQL) सदस्य कार्य "दृश्य" से बहुत अधिक अप्राप्य हैं, इसमें "दृश्य" निर्धारित करता है कि कक्षाओं के लिए क्या आवश्यक है और इसलिए दस्तावेज़ / दृश्य वास्तुकला को तोड़ने के लिए लगता है।

इसके अलावा, ऐसा लगता है कि उदाहरण के लिए यह अक्षम है कि एक सेलेक्ट स्टेटमेंट का चयन केवल वही होना चाहिए जो आवश्यक हो, लेकिन इनवॉइस में सदस्य चर की उपस्थिति का अर्थ "गारंटीकृत डेटा" है।

पता नहीं अगर मैंने स्पष्ट रूप से प्रश्न समझाया, तो इस वास्तुकला / डिजाइन पैटर्न / व्हाट्स-इट-इज़-ए-ज्ञात के रूप में कुछ अन्य सर्वोत्तम दृष्टिकोण क्या हैं?

सलाह के लिए धन्यवाद

जवाबों:


14

वैसे मुझे लगता है कि आप एक ORM का उपयोग कर सकते हैं।

लेकिन वास्तव में, डेटाबेस के डिजाइन को OOP के सिद्धांतों का पालन नहीं करना चाहिए, यह सामान्यीकरण जैसे डेटाबेस के डिजाइन के प्रस्ताव का पालन करना चाहिए। और इसे डेटाबेस में डिज़ाइन किया जाना चाहिए न कि एप्लिकेशन में। और डेटा अखंडता नियमों को डेटाबेस स्तर पर लागू किया जाना चाहिए न कि आवेदन द्वारा।

मेरा सुझाव है कि आप कुछ डेटाबेस डिज़ाइन पुस्तकों को पढ़ें और फिर, अपनी पसंद के डेटाबेस को ट्यून करते हुए प्रदर्शन के बारे में पढ़ें।


5
+1 सब कुछ OOP नहीं होना चाहिए (भले ही कुछ ORM काफी अच्छे हों!)
जेवियर

1
ओ / आरएम अच्छे हैं, लेकिन उनका उपयोग करने का मतलब यह नहीं है कि आप अच्छे डेटाबेस डिजाइन के अनुरूप नहीं हो सकते।
ब्लैकिस

1
@ डेविड, मैं सहमत हूं कि यह किसी के हाथ में सच है जो जानता है कि वह क्या कर रहा है। और मैंने सुझाव दिया कि वह एक ORM को देखता है, लेकिन वास्तव में यदि आप डेटाबेस डिज़ाइन को पहले नहीं जानते हैं, तो ORM एक खतरनाक उपकरण है।
HLGEM

यह एक अच्छा बिंदु है कि डेटा अखंडता नियम डेटाबेस स्तर पर लागू किया जा सकता है। हालाँकि, कभी-कभी कुछ नियमों को लागू करने के लिए यह समझ में आता है (जैसे कि 'परियोजना में हमेशा 5 से अधिक टीम के सदस्य शामिल होने चाहिए') यदि नियम परिवर्तन के अधीन हैं, और केवल आवेदन ही डेटा को संशोधित करेगा।
जॉन ऑनस्टॉट

आवेदन लगभग कभी नहीं केवल एक चीज है जो डेटा को संशोधित करता है। डेटाबेस में डाले गए व्यावसायिक नियमों का बहुत आसानी से उल्लंघन हो जाता है जब किसी को कुछ डेटा फिक्स का समर्थन करने के लिए डेटा के एक बड़े हिस्से में त्वरित बदलाव करने की आवश्यकता होती है।
HLGEM

10

मुझे एक संरचना नहीं मिल सकती है जो एक OOP दृष्टिकोण का पूरक है जो डेटाबेस के कार्यान्वयन को बाधित करता है

ऐसा लगता है कि आप ऑब्जेक्ट-रिलेशनल प्रतिबाधा बेमेल का वर्णन कर रहे हैं ।

इस OODBMS, ORM उपकरण, डेटा एक्सेस टूल के होस्ट को हल करने के लिए कई चीजें हैं ।

मुझे लगता है कि इस तथ्य के बहुत सारे समाधान हैं कि मुझे विश्वास है कि वन ट्रू सॉल्यूशन ™ मौजूद नहीं है।

इसलिए आप अपने ज्ञान में सुरक्षित किसी भी दिशा को चुन सकते हैं कि कुछ लोग इससे नफरत करेंगे और कुछ इसे पसंद करेंगे।


ऐसा लगता है कि यह अधिक कठोर तरीके से है।
जेक

2

यदि आप ORM आवरण का उपयोग नहीं करना चाहते हैं, तो एक डेटाबेस का उपयोग करें जो MongoDB जैसे OOP शैली के भंडारण का समर्थन करता है ।

MongoDB (से "हू मोंगो हमें") एक पार मंच है दस्तावेज़ उन्मुख डेटाबेस प्रणाली। " NoSQL " डेटाबेस के रूप में वर्गीकृत , MongoDB डायनामिक स्कीमा (MongoDB फॉर्मेट BSON ) के साथ JSON- जैसे दस्तावेजों के पक्ष में पारंपरिक टेबल-आधारित रिलेशनल डेटाबेस संरचना को बढ़ाता है , जिससे कुछ प्रकार के अनुप्रयोगों में डेटा का एकीकरण आसान और तेज़ हो जाता है। ..

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.