रिलेशनल डेटाबेस डिज़ाइन पैटर्न? [बन्द है]


283

डिज़ाइन पैटर्न आमतौर पर ऑब्जेक्ट ओरिएंटेड डिज़ाइन से संबंधित होते हैं।
क्या संबंधपरक डेटाबेस बनाने और प्रोग्रामिंग करने के लिए डिज़ाइन पैटर्न हैं ?
कई समस्याओं में निश्चित रूप से पुन: प्रयोज्य समाधान होना चाहिए।

उदाहरणों में तालिका डिज़ाइन, संग्रहीत कार्यविधियाँ, ट्रिगर, आदि के पैटर्न शामिल होंगे ...

क्या ऐसे पैटर्न का ऑनलाइन भंडार है, जो martinfowler.com के समान है ?


समस्याओं का उदाहरण जो पैटर्न हल कर सकते हैं:

  • पदानुक्रमित डेटा संग्रहीत करना (उदाहरण के लिए 1: 1 कुंजी और अंतर के साथ एकाधिक तालिका प्रकार के साथ एकल तालिका ...)
  • चर संरचना के साथ डेटा संग्रहीत करना (जैसे जेनेरिक कॉलम बनाम xml बनाम सीमांकित स्तंभ ...)
  • डेटा को असामान्य करें (इसे कम से कम प्रभाव के साथ कैसे किया जाए, आदि ...)

मैं यहाँ सबसे अच्छा Q & A के लिए श्रेणीबद्ध डेटा स्टोरेज के लिए दावा करूँगा: stackoverflow.com/questions/4048151/…
Orangepips

1
हमारे ऑन-टॉपिक मार्गदर्शन के अनुसार , " कुछ प्रश्न अभी भी ऑफ-टॉपिक हैं, भले ही वे ऊपर सूचीबद्ध श्रेणियों में से एक में फिट हों: ... प्रश्न हमें एक पुस्तक, उपकरण, सॉफ्टवेयर लाइब्रेरी, ट्यूटोरियल या अन्य की सिफारिश या खोजने के लिए कहते हैं। ऑफ-साइट संसाधन ऑफ़-टॉपिक हैं ... "
रॉबर्ट कोलंबिया

@RobertColumbia पर 2008 में सवाल किया गया था , जब पूछा गया ...
Sklivvz

संबंधित डेटाबेस पर डिज़ाइन पैटर्न संसाधनों की इस सूची और सॉफ्टवेयर इंजीनियरिंग के कई क्षेत्रों की
जाँच करें

जवाबों:


150

मार्टिन फाउलर की सिग्नेचर सीरीज़ में एक पुस्तक है जिसे रिफैक्टिंग डेटाबेस कहा जाता है । यह डेटाबेस को फिर से संगठित करने के लिए तकनीकों की एक सूची प्रदान करता है। मैं यह नहीं कह सकता कि मैंने डेटाबेस पैटर्न की एक सूची को बहुत सुना है।

मैं डेविड सी। हाय के डेटा मॉडल पैटर्न और फॉलो अप ए मेटाडेटा मैप की भी अत्यधिक अनुशंसा करता हूं जो पहले पर बनाता है और कहीं अधिक महत्वाकांक्षी और पेचीदा है। अकेले प्रस्तावना ज्ञानवर्धक है।

कुछ पूर्व-कैन्ड डेटाबेस मॉडल को देखने के लिए एक शानदार स्थान है लेन सिल्वरस्टोन के डेटा मॉडल संसाधन बुक सीरीज़ वॉल्यूम 1 में सार्वभौमिक रूप से लागू डेटा मॉडल (कर्मचारी, खाते, शिपिंग, खरीद आदि) शामिल हैं, वॉल्यूम 2 में उद्योग विशिष्ट डेटा मॉडल (लेखा, शामिल हैं) स्वास्थ्य सेवा, आदि), खंड 3 डेटा मॉडल पैटर्न प्रदान करता है।

अंत में, जबकि यह पुस्तक UML और ऑब्जेक्ट मॉडलिंग के बारे में तीव्रता से है, पीटर Coad की मॉडलिंग इन कलर विथ यूएमएल इस आधार पर शुरू होने वाली इकाई मॉडलिंग की "आर्कटाइप" संचालित प्रक्रिया प्रदान करती है कि किसी भी वस्तु या डेटा मॉडल के 4 मुख्य आर्कटाइप हैं।


1
स्कॉट डब्ल्यू एंबलर और प्रमोद जे। सैडल द्वारा पुस्तक का शीर्षक [रिफैक्टरिंग डेटाबेस: एवोल्यूशनरी डेटाबेस डिज़ाइन] [1] है और वास्तव में बहुत अच्छा है। [1]: ambysoft.com/books/refactoringDatabases.html
Panos

3
Ambler पुस्तक के बारे में: नहीं, आप "एक कॉलम डालने" या "FK बाधा पैदा करने" को एक ही कारण के लिए एक पैटर्न के रूप में सूचीबद्ध नहीं कर सकते हैं। 4 पुस्तक की गैंग "लूप" के लिए एक पैटर्न नहीं है।
तेगिरी नेनाशी

यह एक ऐसा पैटर्न नहीं है जो एक रिफैक्टिंग है। जैसे निकालने की विधि, या पैरामीटर का नाम बदलें। रिफैक्टरिंग और पैटर्न हाथ से चलते हैं।
माइकल ब्राउन

एक जोड़ने के लिए: फाउलर द्वारा "विश्लेषण पैटर्न"। हेय के सामान के समान
नील मैकगिन

2
लेन सिल्वरस्टोन का खंड 3 केवल एक है जिसे मैं "डिज़ाइन पैटर्न" के रूप में मानूंगा। पहले 2 शो के सैंपल डेटा मॉडल थे जो पुस्तकों के लिखे जाने के समय सीमा में सामान्य थे। वॉल्यूम 3 हालांकि वास्तव में दिए गए समस्या परिदृश्य के लिए कई डिज़ाइन पैटर्न हैं। उदाहरण के लिए, अध्याय 4 में पदानुक्रम / एकत्रीकरण / सहकर्मी से सहकर्मी परिदृश्य शामिल हैं, और फिर कई डिज़ाइन प्रदान किए गए हैं जो प्रत्येक के पेशेवरों और विपक्षों को संबोधित करते हैं।
डेरेलनॉर्टन

46

डिजाइन पैटर्न तुच्छ पुन: प्रयोज्य समाधान नहीं हैं।

परिभाषा के अनुसार डिज़ाइन पैटर्न पुन: प्रयोज्य हैं। वे ऐसे पैटर्न हैं जिनका आप अन्य अच्छे समाधानों में पता लगाते हैं।

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

संबंधपरक डिज़ाइन पेटेंट में निम्न बातें शामिल हैं:

  1. एक विदेशी कुंजी का उपयोग करते हुए कई-कई रिश्ते (मास्टर-डिटेल, माता-पिता-बच्चे)।

  2. एक पुल की मेज के साथ कई-से-कई संबंध।

  3. वैकल्पिक एक-से-एक रिश्ते FK कॉलम में NULLs के साथ प्रबंधित होते हैं।

  4. स्टार-स्कीमा: आयाम और तथ्य, OLAP डिज़ाइन।

  5. पूरी तरह से सामान्यीकृत ओएलटीपी डिज़ाइन।

  6. एक आयाम में कई अनुक्रमित खोज कॉलम।

  7. "लुकअप तालिका" जिसमें पीके, विवरण और कोड मूल्य (ओं) का उपयोग एक या अधिक अनुप्रयोगों द्वारा किया जाता है। कोड क्यों है? मुझे नहीं पता, लेकिन जब उनका उपयोग किया जाना है, तो यह कोड को प्रबंधित करने का एक तरीका है।

  8. यूनी-तालिका। [कुछ इसे एक विरोधी पैटर्न कहते हैं; यह एक पैटर्न है, कभी-कभी यह बुरा होता है, कभी-कभी यह अच्छा होता है।] यह एक तालिका है जिसमें बहुत सारे पूर्व-शामिल सामान हैं जो दूसरे और तीसरे सामान्य रूप का उल्लंघन करते हैं।

  9. सरणी तालिका। यह एक तालिका है जो कॉलम में मानों की एक सरणी या अनुक्रम होने से पहले सामान्य रूप का उल्लंघन करती है।

  10. मिश्रित-उपयोग डेटाबेस। यह लेन-देन प्रसंस्करण के लिए सामान्यीकृत डेटाबेस है, लेकिन रिपोर्टिंग और विश्लेषण के लिए बहुत सारे अतिरिक्त अनुक्रमित हैं। यह एक विरोधी पैटर्न है - ऐसा मत करो। लोग इसे वैसे भी करते हैं, इसलिए यह अभी भी एक पैटर्न है।

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

और इसमें उपयोग और प्रबंधन के प्रशासनिक और परिचालन पैटर्न शामिल नहीं हैं।


कुछ अन्य पैटर्न जो मैंने देखे हैं वे बहु-अभिभावक चाइल्ड टेबल हैं (जैसे, एक ऑब्जेक्ट और ऑब्जेक्ट के साथ एक वैश्विक नोट्स की तरह जो किसी भी अन्य टेबल से लिंक हो सकता है), या एक स्व-रेफ़रेंशियल FK (यानी, employee.manager -> कर्मचारी)। आईडी)। इसके अलावा मैंने एक सिंगलटन कॉन्फिग टेबल का इस्तेमाल किया है जिसमें कई कॉलम हैं।
r00fus

1
क्यों वास्तव में एक मिश्रित उपयोग डेटाबेस एक विरोधी पैटर्न है। अगर मैं किसी डेटाबेस से रिपोर्ट खींचना चाहता हूं तो मुझे क्या करना है?
जैतून

3
@lhnz: आप एक ट्रांसेक्शनल डेटाबेस डिज़ाइन से बहुत सी बड़ी रिपोर्ट नहीं खींच सकते - रिपोर्टिंग के लिए लॉक करने से लेनदेन धीमा हो जाएगा। कॉम्प्लेक्स के प्रदर्शन के खिलाफ कॉम्प्लेक्स जॉइन (बार-बार प्रदर्शन) एक और दस्तक है। आप एक डेटाबेस में दोनों नहीं कर सकते। बहुत बड़ी रिपोर्ट करने के लिए, आपको डेटा को एक स्टार स्कीमा में स्थानांतरित करना होगा। स्टार स्कीमा पैटर्न रिपोर्टिंग के लिए अनुकूलित है। और डेटा को स्थानांतरित करने से किसी भी लॉक विवाद को हटा दिया जाता है।
S.Lott

यदि आप तालिकाओं को अधिक "कोसिव" डेटा बना रहे हैं तो स्कीमा को पंक्ति लॉक विवाद को सामान्य करना होगा? मेरी सोच यह है कि यदि एक बड़ी तालिका सर्विसिंग के लिए 2 प्रकार के डेटा सेट लिखती है, लेकिन दोनों एक ही पंक्ति में हैं, तो इससे अनावश्यक लॉक विवाद होगा।
CMCDragonkai

6

AskTom शायद Oracle DBs पर सर्वोत्तम प्रथाओं पर सबसे उपयोगी संसाधन है। (मैं आमतौर पर किसी विशेष विषय पर Google क्वेरी के पहले शब्द के रूप में "Asktom" टाइप करता हूं)

मुझे नहीं लगता कि संबंधपरक डेटाबेस के साथ डिजाइन पैटर्न की बात करना वास्तव में उचित है। संबंधपरक डेटाबेस पहले से ही एक समस्या के लिए एक "डिजाइन पैटर्न" का आवेदन है (समस्या को "अखंडता बनाए रखते हुए डेटा के साथ कैसे प्रतिनिधित्व, संग्रह और काम करना है" और डिजाइन संबंधपरक मॉडल है)। अन्य अनुमोदन (आमतौर पर अप्रचलित माना जाता है) नेविगेशनल और पदानुक्रमित मॉडल हैं (और मुझे लगता है कि कई अन्य मौजूद हैं)।

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


4

डेटाबेस विकास के कई वर्षों के बाद मैं कह सकता हूं कि कुछ नहीं हैं और कुछ सवाल हैं जिनका जवाब आपको शुरू करने से पहले देना चाहिए:

प्रशन:

  • क्या आप भविष्य में एक और DBMS का उपयोग करना चाहते हैं? यदि हाँ, तो वर्तमान DBMS के विशेष SQL सामान का उपयोग नहीं करता है। अपने आवेदन में तर्क निकालें।

उपयोग नहीं करता है:

  • तालिका नामों और स्तंभ नामों में सफेद स्थान
  • टेबल और कॉलम नामों में गैर एससीआई अक्षर
  • एक विशिष्ट निचले मामले या ऊपरी मामले के लिए बाध्यकारी। और कभी भी 2 टेबल या कॉलम का उपयोग न करें जो केवल निचले मामले और ऊपरी मामले के साथ भिन्न हो।
  • "FROM", "BETWEEN", "DELETE", आदि जैसे तालिकाओं या स्तंभ नामों के लिए SQL कीवर्ड का उपयोग नहीं करता है

recomendations:

  • यूनिकोड समर्थन के लिए NVARCHAR या समकक्षों का उपयोग करें तो आपको कोडपे की कोई समस्या नहीं है।
  • हर कॉलम को एक अनोखा नाम दें। यह कॉलम को चुनने के लिए जुड़ने में आसान बनाता है। यह बहुत मुश्किल है अगर हर टेबल में एक "ID" या "नाम" या "विवरण" हो। XyzID और AbcID का उपयोग करें।
  • जटिल SQL अभिव्यक्तियों के लिए संसाधन बंडल या समान का उपयोग करें। यह एक और DBMS पर स्विच करना आसान बनाता है।
  • किसी भी डेटा प्रकार पर कड़ी मेहनत नहीं करता है। एक अन्य DBMS में यह डेटा प्रकार नहीं हो सकता है। उदाहरण के लिए ओरेकल दाओं के पास केवल एक संख्या नहीं है।

मुझे उम्मीद है कि यह एक अच्छा शुरुआती बिंदु है।


7
यद्यपि आपकी टिप्पणियां काफी शिक्षाप्रद और उपयोगी हैं, लेकिन वे डिज़ाइन पैटर्न नहीं हैं। वे सर्वोत्तम अभ्यास हैं। धन्यवाद,
Sklivvz

7
मैं अद्वितीय कॉलम नामों की सिफारिश से असहमत हूं। मैं चाहूंगा कि ग्राहक ना कहे। ग्राहक की बात मानने से भी मना करें, जहां पर भी कोई बात नहीं है।
पॉल टॉम्बलिन

1

आपका प्रश्न थोड़ा अस्पष्ट है, लेकिन मुझे लगता है कि UPSERTएक डिजाइन पैटर्न माना जा सकता है। उन भाषाओं के लिए जो लागू नहीं होती हैं MERGE, समस्या को हल करने के लिए कई विकल्प (यदि एक उपयुक्त पंक्तियाँ मौजूद हैं UPDATE; और INSERT) मौजूद हैं।


UPSERT SQL भाषा का एक कमांड और हिस्सा है। यह कोई पैटर्न नहीं है।
टोड R

UPSERT SQL भाषा के कुछ वेरिएंट में एक कमांड है - कई प्लेटफ़ॉर्म में यह नहीं है, या केवल हाल ही में मिला है।
स्टीव होमर

@ToddR - मैंने सुना है (थोड़ा सा निंदनीय) कि "पैटर्न" वास्तव में किसी भाषा या मॉडल में कमियों से ज्यादा कुछ नहीं है, जिसके लिए उपयोगकर्ता को काम के लिए चारों ओर निर्माण करना होगा। मुझे नहीं पता कि यूपीएसईआरटी क्या करता है, लेकिन जब इसे कुछ एसक्यूएल में जोड़ा गया है और अन्य नहीं, तो यह एक पैटर्न है।
मार्टिन एफ

1

निर्भर करता है कि आपको पैटर्न से क्या मतलब है। यदि आप व्यक्ति / कंपनी / लेन-देन / उत्पाद और इस तरह से सोच रहे हैं, तो हाँ - बहुत सारे जेनेरिक डेटाबेस स्कीमा पहले से ही उपलब्ध हैं।

अगर आप सोच रहे हैं कि फैक्ट्री, सिंगलटन ... तो नहीं - आपको इनमें से किसी की ज़रूरत नहीं है क्योंकि वे डीबी प्रोग्रामिंग के लिए बहुत कम स्तर के हैं।

यदि आप डेटाबेस ऑब्जेक्ट नामकरण के बारे में सोच रहे हैं, तो यह सम्मेलनों की श्रेणी के तहत है, प्रति डिजाइन नहीं।

BTW, S.Lott, एक-से-कई और कई-से-कई रिश्ते "पैटर्न" नहीं हैं। वे रिलेशनल मॉडल के मूल बिल्डिंग ब्लॉक हैं।


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