🧙🏿 🕖 🌾 डेटाबेस स्कीमा के लिए एक मामूली गाइड 👎🏼 👩🏿‍🎓 🧝🏽

Mookiezoolook द्वारा फूलों की ज्यामिति

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

लेकिन मूल्यांकन कैसे करें कि कौन सा सर्किट बेहतर है? जब हम डेटाबेस आर्किटेक्चर के बारे में बात करते हैं तो "बेहतर" का क्या अर्थ है? Mail.ru Cloud Solutions की टीमआपकोसॉफ्टवेयर विकास सलाहकार माइक अल्चा की सिफारिशों का पालन करने के लिए आमंत्रित करती है। यह हमें लगता है कि उन्होंने बल्कि सक्षम वास्तुकला के कुछ सिद्धांतों को संक्षेप में प्रस्तुत किया है।

निर्देशक: " मुझे लगता है कि हमें एक SQL डेटाबेस का निर्माण करना चाहिए । " डेवलपर (क्या वह यह भी समझता है कि वह किस बारे में बात कर रहा है, या बस किसी व्यावसायिक पत्रिका में किसी प्रकार का विज्ञापन देखा है? ..): " आप डेटाबेस को किस रंग के लिए चाहते हैं?" "। निर्देशक: " शायद लीलाक के पास सबसे अधिक मेमोरी है । "

कुछ बुनियादी टिप्स

तो, दो मुख्य बातों के लिए प्रयास करना महत्वपूर्ण है :

जानकारी को तालिकाओं में तोड़ते समय, सभी जानकारी संग्रहीत होती है।
भंडारण की अतिरेक न्यूनतम है।

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

यहां कुछ दिशानिर्देश दिए गए हैं :

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

- आप किस पर काम कर रहे हैं?

" इस SQL क्वेरी का अनुकूलन।" यह धीमा हो जाता है, और उपयोगकर्ता शिकायत करना शुरू कर देते हैं।

- और टिप्पणियों में अश्लील भाषा अनुकूलन के लिए आवश्यक है?

- यदि आपने मूल कोड देखा है , तो आप नहीं पूछेंगे।

आइए इन सिफारिशों पर अधिक विस्तार से विचार करें।

1. कम से कम तीसरे सामान्य रूप का उपयोग करें

डेटाबेस आर्किटेक्चर को निम्नलिखित श्रेणियों में विभाजित किया जा सकता है:

पहला सामान्य रूप।
दूसरा सामान्य रूप।
तीसरा सामान्य रूप।
बॉयस-कॉड का सामान्य रूप।

ये श्रेणियां गुणवत्ता के आधार पर वर्गीकरण का प्रतिनिधित्व करती हैं। हम सभी श्रेणियों की संक्षिप्त समीक्षा करेंगे और देखेंगे कि कम से कम तीसरे सामान्य रूप की आवश्यकता क्यों है।

पहला सामान्य रूप

पहले सामान्य रूप के लिए, डेटाबेस में प्रत्येक तालिका के प्रत्येक स्तंभ का प्रत्येक मान परमाणु होना चाहिए। परमाणु का क्या अर्थ है? संक्षेप में, परमाणु मूल्य एक "एकल चीज" है।

उदाहरण के लिए, हमारे पास एक तालिका है:

पहला नाम	उपनाम	आयु	क्षेत्रों
जॉन	हरिणी	27	"" वेबसाइट डिजाइन "," ग्राहक अनुसंधान "}
मैरी	जेन	33	"" दीर्घकालिक रणनीतिक योजना "," भर्ती "}
टॉम	लोहार	35	{"विपणन"}

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

तो यह तालिका पहले सामान्य रूप में नहीं है।

इसे इस रूप में लाने के लिए, प्रत्येक फ़ील्ड में केवल एक मान संग्रहीत किया जाना चाहिए ।

दूसरा सामान्य रूप

दूसरे सामान्य रूप में, कोई भी कॉलम प्राथमिक कुंजी का हिस्सा नहीं है (या जो किसी अन्य प्राथमिक कुंजी के भाग के रूप में कार्य कर सकता है) को प्राथमिक कुंजी के छोटे हिस्से से प्राप्त नहीं किया जा सकता है ।

इसका क्या मतलब है?

मान लीजिए कि आपके पास ऐसी आधार संरचना है (मैंने इस तालिका में प्राथमिक कुंजी के अनुरूप फ़ील्ड पर जोर दिया है):

कर्मचारी कामतत्व	PROJECT_ID	घंटे	कर्मचारी का नाम	परियोजना का नाम
1	1	10	जॉन	"वेबसाइट डिज़ाइन"
2	1	बीस	मैरी	"वेबसाइट डिज़ाइन"

इस परियोजना में, कर्मचारी का नाम कर्मचारी से सीधे तौर पर माना जा सकता है, क्योंकि विचार यह है कि कर्मचारी का नाम विशिष्ट रूप से उसके पहचानकर्ता द्वारा निर्धारित किया जाता है।

इसी तरह, परियोजना का नाम प्रोजेक्ट पहचानकर्ता के द्वारा विशिष्ट रूप से पहचाना जाता है।

इस प्रकार, हमारे पास दो कॉलम हैं जिन्हें प्राथमिक कुंजी भाग से घटाया जा सकता है।

इनमें से प्रत्येक उदाहरण इस तालिका को दूसरे सामान्य रूप से बाहर फेंकने के लिए पर्याप्त होगा।

एक अन्य निष्कर्ष यह है कि यदि तालिका पहले सामान्य रूप में थी और सभी प्राथमिक कुंजी एकल कॉलम हैं, तो तालिका पहले से ही दूसरे सामान्य रूप में है।

तीसरा सामान्य रूप

तालिका के लिए तीसरे सामान्य रूप के अनुरूप होने के लिए, यह दूसरे सामान्य रूप में होना चाहिए, जबकि प्राथमिक एक को छोड़कर, इसमें कोई विशेषता (कॉलम) नहीं होनी चाहिए, जो प्राथमिक कुंजी पर संक्रमणीय रूप से निर्भर हैं।

इसका क्या मतलब है?

मान लें कि आपके पास निम्नलिखित वास्तुकला है (जो आदर्श से बहुत दूर है):

कर्मचारी का नाम	कर्मचारी कामतत्व	आयु	department_number	विभाग का नाम
जॉन	1	27	123	"विपणन"
मैरी	2	33	456	"परिचालन"
टॉम	3	35	123	"विपणन"

इस तालिका में, विभाग_नंबर को कर्मचारी_ से अनुमान लगाया जा सकता है, और विभाग_नाम को विभाग_नंबर से अनुमान लगाया जा सकता है। इसलिए डिपार्टमेंट_नाम ट्रांसमिटिवली एम्प्लॉयी_ड पर निर्भर है!

यदि इस तरह की सकरात्मक निर्भरता है: कर्मचारी_आईडी → विभाग_नंबर → विभाग_नाम, तो यह तालिका तीसरे प्राकृतिक रूप में नहीं है।

इसकी वजह से क्या समस्याएं आती हैं ?

यदि विभाग का नाम इसकी संख्या से लिया जा सकता है, तो प्रत्येक कर्मचारी के लिए इस क्षेत्र को संग्रहीत करना अतिरेक का परिचय देता है।

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

इसके अलावा, यहां ऐसा होता है यदि मैरी कंपनी छोड़ने का फैसला करती है: हमें उसकी पंक्ति को तालिका से हटाना होगा, लेकिन अगर वह परिचालन विभाग में एकमात्र कर्मचारी थी, तो विभाग को भी हटाना होगा।

इन सभी समस्याओं को तीसरे सामान्य रूप में पूरी तरह से टाला जा सकता है।

माँ का शोषण । उसकी बेटी का नाम मदद है! मुझे फर्जी पासपोर्ट के लिए मजबूर किया जाता है

2. प्रतिबंधों के रूप में रक्षा की अंतिम पंक्ति बनाएं

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

प्रतिबंध नियमों को निर्धारित करते हैं, डेटाबेस फ़ील्ड में कौन से मान दर्ज किए जा सकते हैं।

डेटाबेस में रिश्तों को परिभाषित करते समय, विदेशी कुंजी बाधाओं को निर्धारित करना सुनिश्चित करें।

अन्य तालिकाओं में अन्य पंक्तियों से संबंधित पंक्ति को हटाते और अद्यतन करते समय क्या होना चाहिए यह निर्दिष्ट करना सुनिश्चित करें (ON DELETE और OND UPD रूल्स)।

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

सुनिश्चित करें कि तालिका मान स्वीकार्य सीमा में हैं, उदाहरण के लिए, CHECK की सीमा निर्धारित करें, उदाहरण के लिए, किसी उत्पाद की कीमत का हमेशा सकारात्मक मूल्य होता है।

एक दिलचस्प तथ्य : अप्रैल 2020 में, यह सॉफ्टवेयर में ऐसा प्रतिबंध था जिसने मास्को MICEX पर व्यापार को रोका क्योंकि WTI तेल वायदा की कीमत शून्य से नीचे गिर गई थी। मॉस्को स्टॉक एक्सचेंज के विपरीत, न्यूयॉर्क मर्केंटाइल एक्सचेंज एनवाईएमईएक्स ने घटना से एक सप्ताह पहले सॉफ्टवेयर को अपडेट किया था , इसलिए यह सफलतापूर्वक एक नकारात्मक मूल्य पर लेनदेन का संचालन करने में सक्षम था, जो कि विक्रेता से खरीदार को अधिभार के साथ - लगभग। ट्रांस।

सभी PostgreSQL सीमाएं यहां पाई जा सकती हैं ।

3. पूरे पते को कभी भी एक क्षेत्र में न रखें

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

लेकिन क्या करना है यदि आपको यह देखने के लिए कि शहर में कौन सा उत्पाद अधिक लोकप्रिय है, ताकि आप शहर से ग्राहक खरीद को जोड़ सकें? क्या आप यह कर सकते हैं?

यह बहुत कठिन होगा!

चूंकि पूरा पता डेटाबेस फ़ील्ड में एक स्ट्रिंग के रूप में संग्रहीत है, इसलिए आपको सबसे पहले यह पता लगाना होगा कि यह स्ट्रिंग शहर का कितना हिस्सा है! और यह लगभग असंभव कार्य है, इस क्षेत्र में सभी संभव पते प्रारूप दिए गए हैं।

इसलिए, विशिष्ट क्षेत्रों में सार्वभौमिक "पता" फ़ील्ड को तोड़ना सुनिश्चित करें: सड़क, घर का नंबर, शहर, क्षेत्र, ज़िप कोड, और इसी तरह।

एक अन्य पता समस्या - बेनामी फ़ील्ड

यहाँ माइकल्स ब्लाच की पुस्तक द कॉपर बुलेट से सॉफ्टवेयर की गुणवत्ता में सुधार का एक चित्रण है:

क्या संभावित समस्याएं यहां दिखाई दे रही हैं? क्या आप शिकागो की सड़कों से शिकागो शहर को आसानी से पहचान सकते हैं? शायद ऩही।

इसलिए, जानकारी की प्रत्येक इकाई को हमेशा स्पष्ट कॉलम नाम देना याद रखें।

रिज्यूमे कैसे लिखें

- क्या आपको SQL में अनुभव है?

- नहीं (नहीं)।

- तो लिखें: NoSQL विशेषज्ञ।

4. कभी भी पहले और आखिरी नाम को एक क्षेत्र में संग्रहित न करें

पते के साथ स्थिति के समान: नाम और उपनाम की विविधताओं की संख्या बहुत बड़ी है कि उनके बीच स्पष्ट रूप से अंतर किया जा सकता है।

बेशक, आप अंतिम नाम से नाम को अलग कर सकते हैं, अगर उनके बीच कोई स्थान है।

उदाहरण के लिए, "माइक एल्चे" → "माइक" और उपनाम "एल्चे"।

लेकिन क्या होगा यदि उपयोगकर्ता एक मध्य नाम दर्ज करता है? या क्या उसका दोहरा उपनाम है? लेकिन क्या होगा अगर एक मध्य नाम और एक डबल उपनाम हो?

कैसे निर्धारित किया जाए कि नाम कहाँ है और स्ट्रिंग को विभाजित करने के लिए अंतिम नाम कहाँ है? गलतियाँ अपरिहार्य हैं।

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

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

5. तालिका और क्षेत्र के नाम के लिए सम्मेलनों को सेट करें और उनसे चिपके रहें

यह उन डेटा के साथ काम करने के लिए बहुत कष्टप्रद है जो user.firstName, user.lst_name, user.birthDate, और इसी तरह दिखता है।

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

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

और क्या पढ़ें :

डेटाबेस स्कीमा के लिए एक मामूली गाइड