डेटाबेस डिजाइन पर 13 ब्लॉग लेख सर्वोत्तम अभ्यास और युक्तियाँ

जब आप एक डेटाबेस डिज़ाइन कर रहे होते हैं, तो ध्यान में रखने के लिए बहुत कुछ होता है, और हम में से बहुत कम लोग हमारे द्वारा सीखी गई हर मूल्यवान टिप और ट्रिक को याद रख सकते हैं। तो, आइए कुछ ऑनलाइन संसाधनों पर एक नज़र डालते हैं जो डेटाबेस डिज़ाइन युक्तियों और सर्वोत्तम प्रथाओं की सुविधा प्रदान करते हैं। जैसे-जैसे हम आगे बढ़ेंगे, मैं डेटाबेस डिज़ाइन में अपने अनुभव के आधार पर प्रस्तुत किए गए विचारों पर अपनी राय साझा करूँगा।

जाहिर है, यह लेख एक संपूर्ण सूची नहीं है, लेकिन मैंने स्रोतों के एक क्रॉस सेक्शन पर समीक्षा और टिप्पणी करने का प्रयास किया है। उम्मीद है, आपको वह जानकारी मिलेगी जो आपकी आवश्यकताओं और लक्ष्यों के लिए सबसे उपयुक्त है।

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

अनुभवी डिजाइनरों के लिए डेटाबेस युक्तियाँ

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

डेटाबेस दिशानिर्देश (RDBMS/SQL)

स्टीव Djajasaputra द्वारा | SOA, जावा, सॉफ्टवेयर डेवलपमेंट - BlogSpot | 16 जनवरी, 2013

श्री जाजसपुत्र का यह लेख काफी प्रभावशाली है:उन्होंने स्कीमा, इंडेक्स और विचारों के लिए कई युक्तियों को सूचीबद्ध किया है; वह काफी विस्तृत नामकरण परंपरा भी प्रदान करता है। और उसकी युक्तियाँ (और आगे) चलती रहती हैं। चौड़ाई प्रभावशाली है, लेकिन लगभग कोई उदाहरण नहीं हैं। उनकी कुछ बातों को बहस का विषय माना जा सकता है, लेकिन कुल मिलाकर यह एक बहुत ही ठोस प्रस्तुति है।

विशेष रूप से, मैं प्रभावित हुआ कि वह प्राकृतिक बनाम कृत्रिम (यानी, सरोगेट या उत्पन्न) प्राथमिक कुंजी का उपयोग करने के बारे में एक सटीक नियम देता है। वह इसे अच्छा और सरल रखता है, यह निर्दिष्ट करते हुए कि हमें एक प्राकृतिक कुंजी पसंद करनी चाहिए क्योंकि यह सार्थक है। वह कृत्रिम कुंजी के सर्वोत्तम उपयोग के लिए दिशानिर्देश भी प्रदान करता है - विशेष रूप से, जब प्राकृतिक कुंजी अद्वितीय नहीं होती है या जब आपको प्राकृतिक कुंजी के मूल्य को बदलने की आवश्यकता होती है। उन्हीं के शब्दों में:

चूंकि उनके सुझावों की सूची इतनी लंबी है, मैं उन सभी को याद करने की कल्पना नहीं कर सकता। लेकिन प्रत्येक अनुभाग को संदर्भित किया जा सकता है जब आप डेटाबेस डिज़ाइन, प्रदर्शन, संग्रहीत कार्यविधियाँ और संस्करण पर काम कर रहे हों। Oracle-विशिष्ट बिंदुओं पर एक अनुभाग भी है जो उपयोगी होगा यदि आप Oracle के साथ काम कर रहे हैं या समर्थन करने की योजना बना रहे हैं।

कुल मिलाकर, यह एक बहुत ही सार्थक और व्यापक संसाधन है।

बेहतर डेटाबेस डिज़ाइन के लिए 9 युक्तियाँ

जेफरी एडिसन द्वारा | वर्टाबेलो ब्लॉग | 22 सितंबर, 2015

मैं यहां थोड़ा आत्म-प्रचार करूंगा।

बेहतर डेटाबेस डिज़ाइन के लिए 9 युक्तियों का यह लेख एक डिज़ाइनर और आर्किटेक्ट के रूप में मेरे अनुभव पर आधारित है। मुझे डेटाबेस डिज़ाइन के लिए दूसरों की सर्वोत्तम प्रथाओं पर शोध करने से अतिरिक्त अंतर्दृष्टि भी मिली।

मेरी सूची कुछ मुख्य मुद्दों का प्रतिनिधित्व करती है जो डेटा मॉडल के साथ काम करते समय हो सकते हैं। मैंने सुझावों को उस क्रम में व्यवस्थित किया है जिस क्रम में वे परियोजना जीवनचक्र के दौरान होते हैं (बजाय महत्व के या वे कितनी बार उठते हैं) क्योंकि यह कम से कम मेरे विचार से सबसे उपयोगी होगा। पाठक किसी परियोजना के जीवनचक्र के माध्यम से सर्वोत्तम प्रथाओं की इस चेकलिस्ट का अनुसरण कर सकते हैं।

लेख से:

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

मुझे आशा है कि मेरी युक्तियों की सूची मध्यवर्ती और उन्नत डिजाइनरों के लिए उपयोगी है।

20 डेटाबेस डिजाइन सर्वोत्तम अभ्यास

कैगडास बसरनेर द्वारा | कोड बैलेंस - ब्लॉगस्पॉट | 24 जुलाई 2011

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

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

प्लस साइड पर, यह आलेख उन कुछ में से एक था जो ऑब्जेक्ट-रिलेशनल मैपिंग (ओआरएम) ढांचे का उपयोग करने का उल्लेख करता है। कुछ टिप्पणीकार इस बात से असहमत थे कि टिप कैसे लिखी गई थी, लेकिन कम से कम एक ओआरएम ढांचे का उपयोग करने का उल्लेख किया गया है:

फिर भी, इस सूची में सुधार किया जा सकता था। इसे स्पष्ट रूप से उन बिंदुओं की पहचान करनी चाहिए जो केवल कुछ . के लिए विशिष्ट हैं डेटाबेस प्रबंधन प्रणाली (उदाहरण के लिए, SQL सर्वर)। प्रदर्शन, अनुमान, या डिज़ाइन . पर समय बिताने के महत्व के बारे में सटीक आंकड़े रखरखाव . के बजाय और फिर से डिज़ाइन करें अच्छा होता। और उदाहरणों की भी आवश्यकता थी, लेकिन इनमें से अधिकांश लेखों के लिए यह एक मुद्दा है।

यदि आप SQL सर्वर के साथ काम कर रहे हैं, एक ORM ढांचे का उपयोग करने पर विचार कर रहे हैं, या एक लंबे और विस्तृत लेख के बजाय सुझावों की बुलेटेड सूची की आवश्यकता है, तो यह टुकड़ा आपके लिए है।

(नोट:यह लेख कोडबिल्ड, जावा कोड गीक्स और डीज़ोन सहित कई अन्य साइटों पर भी दिखाई दिया।)

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

मिशेल ए. पूलेट द्वारा | SQL सर्वर प्रो | 1 मार्च 2011

सुश्री पूलेट की युक्तियों का एक हिस्सा काफी मानक है और कई अन्य संसाधनों में पाया जा सकता है, लेकिन कुछ असामान्य बिंदु भी हैं। अपने सामान्य बिंदुओं में, वह उप-प्रकार और सुपर-प्रकार (जिसके साथ मैं दृढ़ता से सहमत हूं) के उपयोग को बढ़ावा देती हूं क्योंकि यह ऑब्जेक्ट-ओरिएंटेड डिज़ाइन को प्रतिबिंबित करता है और डेवलपर्स द्वारा आसानी से समझा जा सकता है। उनके लेख से:

सीडीएम और उसके बाद अपने डिजाइन में सुपरटाइप और सबटाइप इकाइयों को शामिल करने से डरो मत। उपप्रकार सुपरटाइप के वर्गीकरण या श्रेणियों का प्रतिनिधित्व करते हैं… जब इकाई को वर्गीकृत करने के लिए एक से अधिक शब्द या वाक्यांश लगते हैं तो संस्थाओं को उपप्रकार के रूप में दर्शाया जाता है।

यदि किसी श्रेणी का अपना जीवन है, अलग-अलग विशेषताओं के साथ जो यह वर्णन करती है कि श्रेणी कैसे दिखती है और व्यवहार करती है और अन्य संस्थाओं के साथ संबंधों को अलग करती है, तो यह सुपरटाइप / उपप्रकार संरचना को लागू करने का समय है . ऐसा करने में विफलता डेटा और डेटा संग्रह को चलाने वाले व्यावसायिक नियमों की पूरी समझ को बाधित करेगी।

उनकी कुछ टिप्पणियाँ MS SQL सर्वर का विशिष्ट संदर्भ देती हैं, भले ही टिप्पणियाँ वास्तव में सामान्य समस्याएँ हों। एक मुख्य बिंदु जो सुश्री पूलेट बनाती हैं, वह बहुत ही SQL सर्वर-विशिष्ट है:"स्टोर कोड जो एक संग्रहीत प्रक्रिया के रूप में डेटाबेस के डेटा को छूता है"।

यह ठीक है यदि आप केवल एकल डेटाबेस प्रबंधन प्रणाली, जैसे SQL सर्वर का समर्थन करने की योजना बना रहे हैं। लेकिन पोर्टेबल कार्यान्वयन के लिए, यह अच्छी सलाह नहीं होगी। आम तौर पर, मैं अलग-अलग संग्रहीत प्रक्रिया भाषा समर्थन के साथ कम से कम दो प्रबंधन प्रणालियों के लिए पोर्टेबिलिटी के लिए डिज़ाइन करता हूं। इसलिए, मैं इस अभ्यास से बचूंगा।

यह लेख उन लोगों के लिए सबसे उपयोगी है जो SQL सर्वर के लिए विकसित हो रहे हैं और अमेरिकी बाजार पर ध्यान केंद्रित कर रहे हैं (एक अंतरराष्ट्रीय प्रणाली के बजाय)। विदेश में रहने वाली एक अमेरिकी के रूप में, हालांकि, मैंने पाया कि उसके कुछ उदाहरण "यूएसए-केंद्रित" हैं। उदाहरण के लिए, एक गैर-अमेरिकी यह नहीं समझ सकता कि Zip+4 . क्या है डोमेन है और इसलिए उसे इस बात की कोई समझ नहीं होगी कि इस डोमेन में NOT NULL विशेषता क्यों होनी चाहिए।

इसे स्पष्ट करने के लिए, मैंने दोनों अमेरिकी गैर-अमेरिकी पतों के लिए एक डेटा मॉडल बनाया। हम मान लेंगे कि हमारे डेटा मॉडल के लिए संस्थाओं को एक से अधिक पते से लिंक करने की आवश्यकता हो सकती है:उदाहरण के लिए, एक बिलिंग के लिए, एक शिपिंग के लिए। पहला पता भुगतान विधि से संबद्ध होगा; इस मामले में, उस भुगतान को अधिकृत करने के आपके अधिकार को सत्यापित करने के लिए पते का उपयोग किया जाएगा। जाहिर है, शिपिंग पता वह जगह है जहां ऑर्डर दिया जाएगा।

आइए ग्राहक-आदेश डेटाबेस मॉडल के हिस्से के रूप में एक अमेरिकी पता बनाएं। (नोट:यह एक पूर्ण मॉडल नहीं है, बल्कि उत्पाद ऑर्डर संग्रहीत करने का एक उदाहरण है।)

समझदार कोडर्स सॉल्यूशंस घर के नंबरों और सड़क के नामों के लिए अलग-अलग क्षेत्रों को परिभाषित करने और इन क्षेत्रों को न्यूल के रूप में सेट करने की सिफारिश करता है; यह किसी भी पते को अस्वीकार कर देगा जिसमें घर का नंबर और सड़क का नाम नहीं है। लेकिन उन लोगों का क्या जो पीओ बॉक्स का इस्तेमाल करते हैं? उनके पते आमतौर पर "पीओ बॉक्स 123" के रूप में लिखे जाते हैं। क्या हमें उन्हें पीओ बॉक्स नंबर को घर का नंबर और "पीओ बॉक्स" को सड़क के नाम के रूप में रखने के लिए मजबूर करना चाहिए? मुझे ऐसा नहीं लगता।

इसके बजाय, हम "पता पंक्ति 1" और "पता पंक्ति 2" वाले प्रपत्र का उपयोग करेंगे। कई लोगों ने फ़ील्ड नामों में संख्याओं का उपयोग करने के खिलाफ तर्क दिया है, लेकिन मेरे लिए यह एक स्पष्ट समाधान है। साथ ही, मैंने अधिकतम फ़ील्ड लंबाई (35 और 70 वर्ण) निर्धारित की हैं जो अंतरराष्ट्रीय भुगतानों में विशिष्ट हैं।

ध्यान दें कि यूएस और गैर-यूएस डिज़ाइन दोनों में एक देश के भीतर क्षेत्रों के लिए एक फ़ील्ड है, लेकिन यूएस डिज़ाइन के लिए आवश्यक है कि 2-वर्ण का राज्य संक्षिप्त नाम शामिल किया जाए। साथ ही, ध्यान दें कि यूएस डिज़ाइन अन्य देशों में पतों की अनुमति नहीं देता है।

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

खराब डेटा वेयरहाउस डिज़ाइन से सीखे गए सबक

मिशेल ए. पूलेट द्वारा | SQL सर्वर प्रो | 15 जून 2009

यह आलेख डेटा वेयरहाउस (DWH) और इसके कुछ डिज़ाइन और कार्यान्वयन मुद्दों पर एक नज़र डालता है। SQL सर्वर पर थोड़ा ध्यान दिया गया है, लेकिन यह डेटा वेयरहाउसिंग और बिजनेस इंटेलिजेंस के लिए डिजाइनिंग का काफी रूढ़िवादी अवलोकन है। बाय-इन करना और उपयोगकर्ता के अनुकूल इंटरफेस बनाना युक्तियों का सबसे उपयोगी नहीं हो सकता है, लेकिन मैं उनसे असहमत नहीं हूं - मुझे नहीं लगता कि वे डीडब्ल्यूएच डिजाइन का हिस्सा हैं।

सुश्री पूलेट का कहना है कि एक्स्ट्रेक्ट-ट्रांसफॉर्म-लोड (ईटीएल) प्रक्रिया को डेटा गुणवत्ता जांच और संभावित रूप से "क्लीन" डेटा करना चाहिए जब तक कि डेटा गुणवत्ता का स्वीकार्य मानक न हो। मेरी राय में, यह डेटा वेयरहाउस बनाने का जोखिम उठाता है जो स्रोत सिस्टम से निकाली गई जानकारी को ठीक से प्रतिबिंबित नहीं करता है। स्रोत प्रणालियों में डेटा की सफाई की जानी चाहिए। ETL को केवल डेटा को रूपांतरित करना चाहिए ताकि उसे डेटा वेयरहाउस में लोड किया जा सके।

एक सकारात्मक नोट पर, पुनर्चक्रण या पुन:प्रयोज्य ईटीएल रूटीन बनाने की सिफारिश अत्यधिक प्रासंगिक है। इसके अलावा, मैं मापनीयता के बारे में सुश्री पूलेट से सहमत हूं। जोखिम प्रबंधन और अनुपालन के बारे में उनकी टिप्पणियां, विशेष रूप से सरबेन्स-ऑक्सले अधिनियम, काफी विशिष्ट लगती हैं; मुझे लगता है कि ये उसके व्यवसाय के क्षेत्र से आते हैं।

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

11 महत्वपूर्ण डेटाबेस डिजाइनिंग नियम जिनका मैं पालन करता हूं

शिवप्रसाद कोइराला द्वारा | कोड परियोजना | फरवरी 25, 2014

मुझे वास्तव में इस लेख की शुरुआत में समझदार और स्पष्ट सलाह पसंद है। 'एप्लिकेशन की प्रकृति पर विचार करें' और 'अपने डेटा को तार्किक टुकड़ों में तोड़ें' जैसी अवधारणाएं हाजिर हैं। आपका डेटा मॉडल बनाते समय ये महत्वपूर्ण सहायता हैं। जैसा कि श्री कोईराला कहते हैं:

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

आपको याद दिलाने के लिए, ओटीएलटी तालिका आम तौर पर कुछ इस तरह दिखती है, जिसमें एक ही तालिका में कई डोमेन से प्रविष्टियां डाली जाती हैं। मैं ओटीएलटी विरोधी समूह से सहमत हूं; ये तालिकाएँ कई मुद्दों का परिचय देती हैं।

इसके अलावा, कुछ बिंदु थोड़े गूढ़ लगते हैं, जैसे "विभाजक द्वारा अलग किए गए डेटा के लिए देखें"। हालांकि यह एक मान्य बिंदु है, यह वह नहीं है जिसके बारे में मैं आमतौर पर एक नया डेटा मॉडल बनाते समय सोचता हूं।

श्री कोईराला के पास कुछ OLAP डिज़ाइन आइटम हैं जिनका आमतौर पर अन्य सर्वोत्तम अभ्यास सूचियों में उल्लेख नहीं किया गया है। एक आयाम और तथ्य डिजाइन का उनका समावेश उपयोगी हो सकता है, लेकिन यह नौसिखिया डिजाइनरों के लिए खतरनाक भी हो सकता है।

यदि आप शुरुआत से अधिक उन्नत डेटा मॉडलिंग में आगे बढ़ रहे हैं तो यह लेख दिलचस्प है। यह आपके भविष्य के मॉडल की विश्लेषणात्मक बनाम लेन-देन की प्रकृति पर विचार करने में आपकी सहायता करेगा।

बिग डेटा:पांच आसान डेटाबेस डिज़ाइन प्रदर्शन युक्तियाँ

डेव बेउल्के द्वारा | davebeulke.com | मार्च 19, 2013

श्री बेउल्के का लेख प्रदर्शन-केंद्रित डिज़ाइन युक्तियों को देखता है। वह दिखाता है कि उचित सामान्यीकरण की जांच कैसे करें:न तो बहुत अधिक और न ही बहुत कम। (अति-सामान्यीकरण का डेटाबेस के प्रदर्शन पर नकारात्मक प्रभाव पड़ेगा।)

साथ ही, जब आप प्रत्येक डेटाबेस एक्सेस के लिए किसी व्यावसायिक कुंजी से जेनरेट की गई पंक्ति आईडी में अनुवाद करने से बचना चाहते हैं, तो जेनरेट की गई प्राथमिक कुंजियों के बजाय प्राकृतिक व्यावसायिक कुंजियों का उपयोग करना उचित सलाह है।

उचित नामकरण मानकों और कॉलम प्रकारों का उपयोग करना भी अच्छी सलाह है। अशक्त स्तंभों के अति प्रयोग के बारे में बात ध्वनि है:सभी स्तंभों को अशक्त के रूप में बनाना एक गलती है, लेकिन किसी विशेष व्यावसायिक कार्य के लिए एक स्तंभ को अशक्त के रूप में परिभाषित करना आवश्यक हो सकता है। लेखक के अपने शब्दों में:

मिस्टर बेउल्के की युक्तियाँ बहुत ठोस हैं, भले ही कुछ हद तक अवास्तविक हों। मैं और अधिक बिग डेटा आइटम पसंद करूंगा - यानी, लेख का शीर्षक। अंत में, मुझे लगा कि लेख में गहराई और चौड़ाई दोनों का अभाव है, और बिंदुओं को स्पष्ट करने के लिए कोई उदाहरण नहीं था। हालांकि, वह सामान्यीकरण और प्राकृतिक कुंजियों से संबंधित बहुमूल्य सलाह देता है।

10 डेटाबेस डिजाइन सर्वोत्तम अभ्यास

एन ऑल द्वारा | एंटरप्राइज़ ऐप्स टुडे | 15 जुलाई 2014

दस डेटाबेस डिज़ाइन सर्वोत्तम अभ्यास वास्तव में स्लाइड की एक श्रृंखला के रूप में प्रस्तुत किए जाते हैं। Ms. All में माइकल ब्लाहा जैसे अनुभवी डेवलपर्स की जानकारी शामिल है। वह आपकी सर्वोत्तम प्रथाओं और पैटर्न के पुन:उपयोग को प्रोत्साहित करता है। इन्हें समझा और सिद्ध किया गया है, और इस संबंध में डेटा मॉडल के लिए बेहतर है जिसे खरोंच से बनाया जाना चाहिए। सुश्री ऑल के लेख से:

यह एक छोटा स्लाइड शो है जिसे डेटा मॉडल डिज़ाइनर जल्दी से स्कैन कर सकते हैं और उन युक्तियों को इकट्ठा कर सकते हैं जो उनके साथ गूंजती हैं। मेरे लिए, पुन:उपयोग टिप मेरे पसंदीदा में से एक है।

डेटाबेस की सर्वोत्तम प्रक्रियाएं

कनिंघम एंड कनिंघम, इंक. द्वारा

इन सर्वोत्तम प्रथाओं की शुरुआत ठीक-ठाक हुई, लेकिन फिर कुछ चिपचिपे मुद्दों में शामिल हो गए। मैं आश्वस्त नहीं हूं कि दी गई सलाह हमेशा सही होती है।

सकारात्मक पक्ष पर, विवादास्पद "सर्वोत्तम प्रथाओं" के बहुत अच्छे विवरण हैं जैसे हमेशा ऑटो-जेनरेटेड सरोगेट कुंजियों का उपयोग करना और संग्रहीत प्रक्रियाओं का उपयोग करना या उनसे बचना। उदाहरण के तौर पर:

(लेखक का नोट:Google पर इन दो वाक्यों को खोजने पर मुझे यह "पिछला लेखक" नहीं मिला।)

और Auto Keys बनाम Domain Keys बहस के प्रत्येक पक्ष पर मुख्य तर्कों के बारे में एक सारांश लेख का लिंक प्रदान किया गया है।

दूसरी ओर, मुझे "ऑपरेटिंग सिस्टम, डेटा को विभाजित करने और विभिन्न भौतिक डिस्क पर लॉगिंग करने" और "RAID का उपयोग करने" के लिए थोड़ा रहस्यमयी सुझाव मिले। मुझे गलत मत समझो - यह शायद कुछ परिस्थितियों में अच्छी सलाह है, लेकिन मैं इसे अपनी शीर्ष 20 सूची में शामिल नहीं करूंगा।

डेटाबेस डिज़ाइन युक्तियाँ

समझदार कोडर्स द्वारा

इस संग्रह में कुछ अनूठी और दिलचस्प युक्तियां हैं, जैसे लेनदेन को जल्द से जल्द बंद करने की सिफारिश।

हालाँकि, मैं यहाँ सभी डिज़ाइन युक्तियों से पूरी तरह सहमत नहीं हूँ। उदाहरण के लिए:

यह विवादास्पद है, कम से कम कहने के लिए - अन्य स्रोत इस तरह "गुप्त कोड" को नियोजित करने के खिलाफ अनुशंसा करते हैं। इसके बजाय, इन स्थिति कोडों को संग्रहीत करने के लिए एक अलग तालिका का उपयोग करें।

इसके अलावा, प्रदर्शन संकेतों से जुड़े आंकड़े संदिग्ध हैं, और लेख में कोई उदाहरण नहीं हैं।

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

शुरुआती डेटाबेस डिज़ाइनर के लिए संसाधन

आइए अब उन लोगों के लिए कुछ लेखों की जांच करें जो अभी डेटाबेस डिजाइन में शुरुआत कर रहे हैं।

वेब विकास में अच्छे डेटाबेस डिजाइन की मूल बातें

कायला नाइट द्वारा | Onextrapixel.com | मार्च 17, 2011

यहां हम कार्यक्षमता से लेकर मॉडलिंग टूल तक की सलाह के साथ थोड़ा और उन्नत होते हैं।

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

लेख की शुरुआत हमें केवल डेटाबेस के बारे में नहीं, बल्कि कार्यक्षमता के बारे में व्यापक रूप से सोचने के लिए कहने के साथ होती है:

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

मुझे लगता है कि यह लेख शुरुआती डेटाबेस डिजाइनरों के लिए एक अच्छा परिचय होगा, और इसे गीक गर्ल के साथ अच्छी तरह से काम करना चाहिए। श्रृंखला।

डेटाबेस डिज़ाइन युक्तियों को एक्सप्लोर करना

डौग लोव द्वारा | डमी के लिए

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

यहाँ श्री लोव की सामान्य ज्ञान युक्तियों में से एक है:

SQL सर्वर के साथ काम करते समय ये अनुशंसाएँ सबसे उपयुक्त होती हैं।

पांच सरल डेटाबेस डिजाइन युक्तियाँ

लैमोंट एडम्स द्वारा | टेकरिपब्लिक | 25 जून 2001

इस संसाधन के लिए मुख्य शब्द "सरल" है। आप इस जानकारी को अन्य लेखों में अधिक स्पष्टीकरण और उदाहरणों के साथ पा सकते हैं।

हालांकि, श्री एडम्स की "उपयोगकर्ता की चाबियों को दूर ले जाने" की सलाह एक दिलचस्प बिंदु है, जिसका शायद ही कभी अन्य स्थानों पर उल्लेख किया गया हो। वह जारी है:

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

मैं अंतिम बिंदु से असहमत था। वह आपके द्वारा डिज़ाइन की गई प्रत्येक तालिका के लिए "फज फ़ैक्टर" की अनुशंसा करता है:

मेरे दिमाग में, यह मूल रूप से "अंत में कुछ अतिरिक्त टेक्स्ट फ़ील्ड जोड़ना" है। ऐसा लगता है कि यह श्री एडम्स की कुछ अन्य युक्तियों का खंडन करता है, विशेष रूप से व्यावसायिक आवश्यकताओं को समझने और सार्थक नामों का उपयोग करने के संबंध में। इन अतिरिक्त ठगना क्षेत्रों को बस "अतिरिक्त 1", या "अतिरिक्त 2" जैसा कुछ कहा जाएगा। उनके व्यवसाय की क्या आवश्यकता है? और ये सार्थक नाम कैसे हैं? जबकि मुझे उनकी अधिकांश डिज़ाइन युक्तियाँ पसंद हैं, यह "धोखा कारक" ऐसा कुछ नहीं है जिसका मैं पालन करता हूं।

डेटाबेस डिज़ाइन:माननीय उल्लेख

जाहिर है, ऐसे अन्य लेख हैं जो डेटाबेस डिज़ाइन युक्तियों और सर्वोत्तम प्रथाओं का वर्णन करते हैं। आप निम्नलिखित लिंक में अतिरिक्त सामग्री पा सकते हैं:

संबंधपरक डेटाबेस डिजाइन:एक सर्वोत्तम अभ्यास प्राइमर | डिजिटल एथोस द्वारा | 24 दिसंबर, 2012

डेटाबेस स्कीमा डिज़ाइन (शुरुआती) के लिए सर्वोत्तम अभ्यास | जिम मर्फी द्वारा | 28 मार्च 2011

आईटी सर्वोत्तम अभ्यास:डेटाबेस डिजाइन | नेब्रास्का-लिंकन विश्वविद्यालय द्वारा

ऑनलाइन डेटाबेस डिजाइन संसाधन:आप कहां जाएंगे?

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

कृपया बेझिझक अतिरिक्त लेखों की अनुशंसा करें।