क्या आप अपने डेटाबेस डिज़ाइन के साथ इन सरल गलतियों को कर रहे हैं?

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

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

डाटाबेस गलती # 1: एक टेबल में फ़ील्ड दोहराएं

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

सौभाग्य से, दोहराव वाले फ़ील्ड आमतौर पर स्पॉट करना आसान होता है। बस इस टेबल पर एक नज़र डालें:

आदेश कामतत्व	उत्पाद 1	PRODUCT2	Product3
1	टेडी भालू	जेली फलियां
2	जेली फलियां

क्या होता है जब किसी ऑर्डर में चार उत्पाद होते हैं? हमें तीन से अधिक उत्पादों का समर्थन करने के लिए तालिका में एक और फ़ील्ड जोड़ने की आवश्यकता होगी। और यदि हमने डेटा इनपुट करने में हमारी सहायता के लिए तालिका के चारों ओर एक क्लाइंट एप्लिकेशन बनाया है, तो हमें इसे नए उत्पाद फ़ील्ड के साथ संशोधित करने की आवश्यकता हो सकती है। और हम ऑर्डर में जेलीबीन्स के साथ सभी ऑर्डर कैसे प्राप्त करते हैं? हमें तालिका में प्रत्येक उत्पाद फ़ील्ड को एसक्यूएल कथन के साथ पूछने के लिए मजबूर होना होगा जो इस तरह दिख सकता है: उत्पाद से चुनें * उत्पाद 1 = 'जेली बीन्स' या उत्पाद 2 = 'जेली बीन्स' या उत्पाद 3 = 'जेली बीन्स'।

एक ही टेबल रखने के बजाय जो सभी जानकारी एक साथ रखती है, हमारे पास तीन टेबल होनी चाहिए जिनमें प्रत्येक के पास एक अलग जानकारी हो। इस उदाहरण में, हम ऑर्डर तालिका के बारे में जानकारी के साथ ऑर्डर तालिका चाहते हैं, हमारे सभी उत्पादों और एक उत्पाद ऑर्डर टैबलेट के साथ एक उत्पाद तालिका जो उत्पादों को ऑर्डर में जोड़ती है।

आदेश कामतत्व	ग्राहक आईडी, ग्राहक पहचान	आदेश की तारीख	संपूर्ण
1	7	1/24/17	19.99
2	9	1/25/17	24.99

उत्पाद आइ डि	उत्पाद	गिनती
1	टेडी भालू	1
2	जेली फलियां	100

ProductOrderID	उत्पाद आइ डि	आदेश कामतत्व
101	1	1
102	2	1

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

डाटाबेस गलती # 2: एक टेबल में एक टेबल एम्बेड करना

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

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

SalesID	प्रथम	अंतिम	पता	फ़ोन नंबर	कार्यालय	कार्यालय का नम्बर
1	सैम	इलियट	118 मुख्य सेंट, ऑस्टिन, TX	(215) 555-5858	ऑस्टिन डाउनटाउन	(212) 421-2412
2	ऐलिस	लोहार	504 2 स्ट्रीट, न्यूयॉर्क, एनवाई	(211) 122-1821	न्यूयॉर्क (पूर्व)	(211) 855-4541
3	जो	पल्ली	428 अकर सेंट, ऑस्टिन, TX	(215) 545-5545	ऑस्टिन डाउनटाउन	(212) 421-2412

हालांकि यह तालिका ऐसा लग सकती है कि यह व्यक्तिगत विक्रेता से संबंधित है, वास्तव में तालिका में एम्बेडेड एक टेबल है। ध्यान दें कि Office और OfficeNumber "ऑस्टिन डाउनटाउन" के साथ दोहराया गया है। क्या होगा अगर एक कार्यालय फोन नंबर बदलता है? आपको जानकारी के एक टुकड़े को बदलने के लिए डेटा का एक पूरा सेट अपडेट करना होगा, जो कभी भी अच्छी बात नहीं है। इन क्षेत्रों को अपनी मेज पर ले जाया जाना चाहिए।

SalesID	प्रथम	अंतिम	पता	फ़ोन नंबर	OfficeID
1	सैम	इलियट	118 मुख्य सेंट, ऑस्टिन, TX	(215) 555-5858	1
2	ऐलिस	लोहार	504 2 स्ट्रीट, न्यूयॉर्क, एनवाई	(211) 122-1821	2
3	जो	पल्ली	428 अकर सेंट, ऑस्टिन, TX	(215) 545-5545	1

OfficeID	कार्यालय	कार्यालय का नम्बर
1	ऑस्टिन डाउनटाउन	(212) 421-2412
2	न्यूयॉर्क (पूर्व)	(211) 855-4541

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

डाटाबेस गलती # 3: एकल क्षेत्र में जानकारी के दो या अधिक टुकड़े डालना

बिक्री व्यक्ति तालिका में कार्यालय की जानकारी एम्बेड करना उस डेटाबेस के साथ एकमात्र समस्या नहीं थी। पता फ़ील्ड में जानकारी के तीन टुकड़े थे: सड़क का पता, शहर और राज्य। डेटाबेस में प्रत्येक फ़ील्ड में केवल एक ही जानकारी होनी चाहिए। जब आपके पास एक ही फ़ील्ड में जानकारी के कई टुकड़े होते हैं, तो जानकारी के लिए डेटाबेस से पूछना कठिन हो सकता है।

उदाहरण के लिए, अगर हम ऑस्टिन के सभी बिक्री लोगों पर एक प्रश्न चलाने के लिए चाहते हैं तो क्या होगा? हमें पता फ़ील्ड में खोजना होगा, जो न केवल अक्षम है, बल्कि खराब जानकारी वापस कर सकता है। आखिरकार, अगर कोई पोर्टलैंड, ओरेगॉन में ऑस्टिन स्ट्रीट पर रहता है तो क्या होता है?

तालिका इस तरह दिखनी चाहिए:

SalesID	प्रथम	अंतिम	पता 1	पता द्वितीय	शहर	राज्य	ज़िप	फ़ोन
1	सैम	इलियट	118 मुख्य सेंट		ऑस्टिन	टेक्सास	78720	2155555858
2	ऐलिस	लोहार	504 दूसरा सेंट		न्यूयॉर्क	न्यूयॉर्क	10022	2111221821
3	जो	पल्ली	428 अकर सेंट	एप 304	ऑस्टिन	टेक्सास	78716	2155455545

यहां ध्यान देने योग्य कुछ चीज़ें हैं।सबसे पहले, "पता 1" और "पता 2" दोहराए गए फ़ील्ड गलती के अंतर्गत आते हैं।

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

साथ ही, बोनस गलती से बचने के लिए, ध्यान दें कि फोन नंबर के लिए स्वरूपण तालिका से अलग कैसे किया गया है। जब भी संभव हो तो आपको फ़ील्ड के प्रारूप को संग्रहित करना चाहिए। फोन नंबरों के मामले में, लोग एक फोन नंबर लिखने के कई तरीके हैं: 215-555-5858 या (215) 555-5858। यह एक बिक्री व्यक्ति को अपने फोन नंबर से खोज कर या उसी क्षेत्र कोड में बिक्री लोगों की तलाश करना अधिक कठिन होगा।

डाटाबेस गलती # 4: एक सही प्राथमिक कुंजी का उपयोग नहीं कर रहा है

ज्यादातर मामलों में, आप अपनी प्राथमिक कुंजी के लिए स्वचालित रूप से वृद्धि संख्या या कुछ अन्य जेनरेट किए गए नंबर या अल्फान्यूमेरिक का उपयोग करना चाहेंगे। आपको प्राथमिक कुंजी के लिए किसी वास्तविक जानकारी का उपयोग करने से बचना चाहिए, भले ही ऐसा लगता है कि यह एक अच्छा पहचानकर्ता बन जाएगा।

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

और यह एक महत्वपूर्ण मूल्य के रूप में वास्तविक जानकारी का उपयोग करने में समस्या है। यह बदल सकता है।

डाटाबेस गलती # 5: नामकरण सम्मेलन का उपयोग नहीं

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

बस कल्पना करें कि प्रक्रिया कितनी मुश्किल होगी यदि नाम फर्स्टनाम के रूप में संग्रहीत किए गए थे, अंतिम तालिका एक तालिका में और first_name, last_name किसी अन्य तालिका में।

दो सबसे लोकप्रिय नामकरण सम्मेलन क्षेत्र में हर शब्द के पहले अक्षर को कैपिटल करना या अंडरस्कोर का उपयोग करके शब्दों को अलग करना है। आप कुछ डेवलपर्स को पहले शब्द को छोड़कर प्रत्येक शब्द के पहले अक्षर को कैपिटल करना भी देख सकते हैं: firstName, lastName।

आप एकवचन तालिका के नाम या बहुवचन तालिका नामों का उपयोग करने पर भी निर्णय लेना चाहेंगे। क्या यह ऑर्डर टेबल या ऑर्डर टेबल है? क्या यह ग्राहक तालिका या ग्राहक तालिका है? फिर, आप ऑर्डर टेबल और ग्राहक तालिका से फंसना नहीं चाहते हैं।

आपके द्वारा चुने गए नामकरण सम्मेलन वास्तव में नामकरण सम्मेलन को चुनने और चिपकने की प्रक्रिया के रूप में महत्वपूर्ण नहीं है।

डाटाबेस गलती # 6: अनुचित इंडेक्सिंग

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

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

निर्णय कैसे लें? यह डेटाबेस डिजाइन की कला का हिस्सा है। टेबल पर आपको कितनी अनुक्रमणिका डालना चाहिए इस पर कोई कठोर सीमा नहीं है। मुख्य रूप से, आप किसी भी फ़ील्ड को इंडेक्स करना चाहते हैं जिसे अक्सर WHERE क्लॉज में उपयोग किया जाता है। अपने डेटाबेस को सही तरीके से अनुक्रमणित करने के बारे में और पढ़ें।