आप डेटाबेस डिज़ाइन के बारे में क्या सोचते हैं? [बन्द है]

Question

मैं मुख्य रूप से एक वेब डेवलपर हूं और मेरे पास कुछ व्यक्तिगत परियोजनाएं हैं जिन्हें मैं बंद करना चाहता हूं।

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

तो आप वेब एप के नजरिए से डेटाबेस को कैसे अप्रोच करते हैं? आप कैसे शुरू करते हैं और आप क्या देखते हैं? सावधानी के लिए झंडे क्या हैं?

Comments

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

— रॉबर्ट हार्वे

@harvey ऐसी कोई भी किताब जिसकी आप सिफारिश करना चाहें?

— १10

Answer 1

डेटाबेस डिजाइन के संबंध में मैंने जो सबसे अच्छी पुस्तक खरीदी थी, वह माइकल हर्नान्देज़ आईएसबीएन: 0-201-69471-9 द्वारा डेटाबेस मॉर्टल्स के लिए डेटाबेस डिज़ाइन थी । अमेज़ॅन लिस्टिंग मैंने देखा कि उसका तीसरा संस्करण है।

तीसरे संस्करण के लिए लिंक

वह एक डेटाबेस डिजाइन करने की (शुरू से अंत तक) की पूरी प्रक्रिया के माध्यम से आपको चलता है। मैं आपको इस पुस्तक से शुरू करने की सलाह देता हूं।

आपको समूह या विखंडू में चीजों को देखना सीखना होगा। डेटाबेस डिज़ाइन में साधारण बिल्डिंग ब्लॉक्स हैं जैसे प्रोग्रामिंग होती है। यदि आप इन सरल बिल्डिंग ब्लॉक्स को पूरी तरह से समझ लेते हैं तो आप किसी भी डेटाबेस डिज़ाइन से निपट सकते हैं।

आपके पास प्रोग्रामिंग में:

• यदि निर्माण करता है
• अगर एल्स कंस्ट्रक्ट करता है
• लूप करते समय
• लूप्स तक करें
• केस का निर्माण

आपके पास डेटाबेस के साथ:

• डेटा टेबल्स
• तालिकाओं को देखो
• वन टू वन रिलेशनशिप
• एक से कई रिश्ते
• बहुत से रिश्तों को
• प्राथमिक कुंजी
• विदेशी कुंजी

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

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

वेब यह चुनौतियों का अपना सेट लाता है। बैंडबाजे के मुद्दे। Statelessness। प्रक्रियाओं से त्रुटिपूर्ण डेटा जो शुरू होते हैं लेकिन कभी समाप्त नहीं होते हैं।

Answer 2

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

3nf सामान्यीकरण का अभ्यास करने से मुझे एकल जिम्मेदारी सिद्धांत के कुछ प्रकार का अभ्यास करने में मदद मिलती है। एक तालिका को आपके सिस्टम में एक अवधारणा का प्रतिनिधित्व करना चाहिए - और अवधारणाओं को एक दूसरे से संबंधित होना चाहिए ताकि वे वास्तविकता की नकल करने का प्रयास करें; उदाहरण के लिए, यदि मैं एक ऐसी प्रणाली का निर्माण कर रहा हूं, जहां एक ग्राहक के पास 0 या कई गतिविधियां हो सकती हैं, तो मैं एक ग्राहक तालिका और एक गतिविधि तालिका बनाता हूं। गतिविधि तालिका का ग्राहक तालिका में एक विदेशी कुंजी संबंध है। जब मैं संग्रहीत प्रक्रियाओं का निर्माण कर रहा हूं, तो मैं ग्राहक और गतिविधि में शामिल होने के लिए एक बाहरी जुड़ाव का उपयोग करना सुनिश्चित करूंगा क्योंकि व्यवसाय की आवश्यकता है कि ग्राहक के पास 0 गतिविधियां हो सकती हैं।

मैं पुल (लिंक) टेबलों का उपयोग करके विस्तार के अवसरों के लिए भी देखता हूं। उदाहरण के लिए, यदि मैं एक व्यावसायिक नियम का प्रतिनिधित्व करने की कोशिश कर रहा था, जहां एक पुस्तक में लेखकों के लिए असीमित (चर) संख्या हो सकती है, तो मैं एक पुस्तक तालिका, एक लेखक तालिका और एक पुल / लिंक तालिका बनाऊंगा जिसमें दोनों के लिए विदेशी प्रमुख संदर्भ हों पुस्तक और लेखक।

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

Answer 3

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

Comments

ORM आपके स्कीमा का आविष्कार नहीं करता है। यह आपके ऑब्जेक्ट में आपके द्वारा किए गए कार्यों के आधार पर बनाता है। यदि आप अपने स्कीमा से अपनी वस्तुओं का निर्माण करते हैं, तो आप वास्तव में अपने बेवकूफ ओआरएम को एक महत्वपूर्ण कार्य सौंप रहे हैं।

@ Pierre303 स्कीमा उस ORM के अंदर प्रोग्रामिंग नियमों से बना है जो शायद आपकी स्थिति / डिज़ाइन के साथ पूरी तरह से जाली नहीं है। यह एक सबऑप्टिमल डेटाबेस बना सकता है। मैंने देखा है कि कुछ भयानक सामान ओआरएम से क्वेरी स्तर पर भी निकलते हैं।

— m4tt1mus

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

— एचएलजीईएम

@HLEMEM: आपने संभवतः हाइबरनेट जैसे उन्नत ORM के साथ काम नहीं किया है और उस टिप्पणी को लिख सकते हैं

ओह, ऑरम कैसे आपके आवेदन के अलावा अन्य चीजों के लिए ऑडिटिंग और फ़ील्ड को संभालती है?

— HLGEM

Answer 4

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

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

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

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

Answer 5

डेटाबेस डिजाइन पूरी तरह से यह विचार किए बिना नहीं किया जा सकता है कि डेटा का उपयोग कैसे किया जाएगा, इसलिए यहां चरणों की एक छोटी सूची है:

• संस्थाओं के बीच संबंधों पर कब्जा करने वाले छोटे वाक्य लिखें
• वाक्यों का प्रतिनिधित्व करने वाला इकाई-संबंध आरेख बनाएं
• ईआर आरेख से एक सामान्यीकृत तार्किक डेटा मॉडल बनाएं
• अनुप्रयोगों और संस्थाओं के लिए एक CRUD मैट्रिक्स बनाओ
• प्रत्येक इकाई के जीवनचक्र के कवरेज को सत्यापित करने के लिए मैट्रिक्स का उपयोग करें
• प्रत्येक आवेदन के लिए सबसकेम निकालें
• प्रत्येक प्रमुख / CRUD ऑपरेशन के लिए उपसमूह पर नेविगेशन पथों की जाँच करें
• उन रिपोर्टों पर विचार करें जिनकी आवश्यकता होगी
• उपरोक्त सभी के आधार पर भौतिक डेटा मॉडल तैयार करना; जहां उपयुक्त हो, स्टार स्कीमा का विभाजन, विभाजन और उपयोग करें

Comments

अगर आप चेक लिखने वाले लोगों को खुश करने की योजना बनाते हैं तो आप बेहतर तरीके से सुनिश्चित कर सकते हैं कि आपको रिपोर्ट सही मिले।

— जेएफओ

Answer 6

डेटाबेस को सफलतापूर्वक डिज़ाइन करने के लिए आपको पहले कई चीजों पर विचार करने की आवश्यकता है:

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

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

फिर आपको प्रदर्शन ट्यूनिंग को समझने की आवश्यकता है। यह समय से पहले नहीं है, प्रदर्शन अधिकांश डेटाबेस की महत्वपूर्ण विफलता बिंदु है और लाखों रिकॉर्ड होने के बाद इसे ठीक करना बहुत कठिन है।

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

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

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

Answer 7

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

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

एक सभ्य मॉडल के निर्माण के संदर्भ में - @ यह डेटाबेस के लिए नीचे है और मौलिक रूप से आपके ऑब्जेक्ट मॉडल का निर्माण व्यापक रूप से समान होने जा रहा है - क्या अद्वितीय है, क्या एक पदानुक्रम है, जहां कई रिश्तों के लिए कई हैं, आदि, फिर भी, हालांकि आप एक डेटाबेस में जाओ, सुनिश्चित करें कि आप सभी अच्छे सामान करते हैं।

यह भी सुनिश्चित करें कि आपके पास स्क्रैच से स्कीमा बनाने के लिए कोड में स्क्रिप्ट या ddl है और अपडेट करने के लिए जब आप परिवर्तन करें (कोड में ddl मेरा पसंदीदा तरीका है - मेरे पास एक सिस्टम है और यह काम करता है)।

Answer 8

मैं एक बड़े व्हाइटबोर्ड और कलम के विभिन्न रंगों के एक गुच्छा के साथ शुरू करता हूं। अलग-अलग रंगों का मतलब अलग-अलग चीजों से है। और मैं सिर्फ ड्राइंग शुरू करता हूं। आमतौर पर मैं उन चीजों को आकर्षित करता हूं जो काले रंग में निश्चित होती हैं, जो चीजें नीले रंग में होती हैं, और ऐसी चीजें जो हरे रंग में नहीं होती हैं। लाल महत्वपूर्ण नोटों के लिए है। मैं मिटा और लालच से। मुझे लगता है कि मुझे किस तरह की चीजों की जरूरत है और सुनिश्चित करें कि मॉडल इसका समर्थन करता है। अगर ऐसा नहीं होता तो मैं तब तक ट्विक करूंगा।

आखिरकार, अगर मॉडल बहुत बड़ा हो जाता है, तो मैं इसे Visio में स्थानांतरित कर दूंगा और व्हाइटबोर्ड पर टुकड़ों पर काम करूंगा।

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

"एसक्यूएल फिर ओआरएम" या इसके विपरीत, जैसा कि आप पर निर्भर है। बस यह सुनिश्चित करें कि आपका मॉडल पहले एक अच्छी नींव बनाता है।

Comments

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

— मर्फ़

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

— हॉन्शेल

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

— हॉन्शेल

Answer 9

मैं वस्तुओं को पहले डिजाइन करता हूं फिर स्कीमा बनाने के लिए मैं एक ORM (जैसे nHibernate) का उपयोग करता हूं। यह मुझे उलटा करने की तुलना में बहुत अधिक लचीलापन देता है।

अगला चरण उत्पन्न स्कीमा का अनुकूलन है।

यह एक लंबा समय हो गया है जब मैंने एक परियोजना देखी है जहां डेटाबेस तालिकाओं को पहले डिजाइन किया गया था।

Comments

हाँ। जब तक आप एक डीबी गुरु नहीं हैं, db को यथासंभव सरल रखें। यह केवल ऐप का समर्थन करने के लिए पर्याप्त होना चाहिए। पूर्व अनुकूलन खराब है। प्री-ऑप्टिमाइज़ेशन जब आप नहीं जानते कि आप जो कर रहे हैं वह भयानक है। यदि आप समस्याओं में भाग लेते हैं (और आप शायद नहीं करेंगे) तो केवल एक वास्तविक विशेषज्ञ में लाएं।

— एलग्रिन्गोग्रांड

@ElGringoGrande जब तक आप एक dbguru नहीं हैं, आपके पास कोई व्यवसाय नहीं है, लेकिन किसी भी डेटाबेस के लिए एक डेटाबेस डिजाइन किया गया है। यदि इसे 10 से अधिक तालिकाओं की आवश्यकता होगी और यह 100000 से अधिक रिकॉर्ड नहीं रखेगा और आपके पास एक पेशेवर डेटाबेस डिजाइनर नहीं है, तो आप इसे गलत कर रहे हैं।

— HLGEM

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

— ElGringoGrande

ElGringoGrande: यदि आपने ऐसे डेटाबेस डिज़ाइन किए हैं, जिसमें सैकड़ों समवर्ती उपयोगकर्ता और लाखों पंक्तियाँ तालिकाओं में हैं और उपयोगकर्ता खुश हैं, तो आप db-guru हैं। शायद आपने इसे महसूस नहीं किया है, फिर भी।

— ypercube y

Answer 10

अन्य फैलो द्वारा अब तक स्पष्ट रूप से नहीं बताई गई कुछ चीजें:

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

• सिस्टम के उद्देश्यों और उपयोगकर्ता की आवश्यकताओं को अच्छी तरह से जानें। आवश्यकताओं को जाने बिना आप सही डेटा मॉडल को डिज़ाइन नहीं कर सकते।

• पता है कि कार्यक्रमों में कौन सा कोड करना है और कौन सा कोड डीबी को ध्यान रखना है। यह आवश्यक है ताकि आप डेटा कॉलम की नल, शून्य, आदि को ठीक से सेट करें। यह भी आवश्यक है ताकि आप अपने आरआई को सही ढंग से निर्दिष्ट करें।

• अपनी प्राथमिक कुंजियों को अच्छी तरह से निर्धारित करें। जब आप कर सकते हैं सरल कुंजी के लिए जाओ।

• अन्य अनुप्रयोगों के साथ एकीकरण की जरूरतों पर विचार करें।

• सार्वभौमिक डेटा मॉडल का उपयोग करने पर विचार करें और नामकरण और डेटा कॉलम आकार में उद्योग के मानकों का पालन करें।

• भविष्य की जरूरतों के बारे में सोचें (जब ज्ञात हो और जब लागू हो)

• अपने मोड की समीक्षा दूसरों द्वारा करें।

• मॉडलिंग के लिए एक टूल का उपयोग करें - या तो एक ERD टूल या एक UML टूल।

• जनरेट किए गए डीडीएल कोड की समीक्षा करें और समझें। इसे मत लेना।