डेटाबेस डिझाइन केलेले सामान्य चुका

आपण रेकॉर्ड केलेल्या शेकडो नोंदी किंवा लाखो रेकॉर्ड असलेल्या एखाद्या डेटाबेससह कार्य करत असलात तरीही, योग्य डेटाबेस डिझाइन करणे नेहमी महत्त्वाचे असते. ह्यामुळे माहिती अधिक सोपी मिळणार नाही, तर भविष्यात डाटाबेसचा विस्तार करणे देखील सोपे होईल. दुर्दैवाने, काही फॅशनमध्ये येणे सोपे आहे जे भविष्यात गोष्टी कठीण करू शकते.

डेटाबेसचे सामान्यीकरण करण्याच्या विषयावर सर्व पुस्तके लिहिलेली आहेत, परंतु जर आपण ही सामान्य चुका टाळल्या तर आपण योग्य डेटाबेस डिझाईनच्या योग्य मार्गावर असाल.

डेटाबेस चूक # 1: सारणी मध्ये पुनरावृत्ती फील्ड

चांगल्या डेटाबेस डिझाइनसाठी थंबचे एक मूलभूत नियम म्हणजे पुनरावृत्ती झालेले डेटा ओळखणे आणि त्या पुनरावृत्त स्तंभ त्यांच्या स्वतःच्या टेबलमध्ये ठेवणे. टेबलमधील पुनरावृत्ती क्षेत्र जे स्प्रेडशीटच्या जगातून आले आहे ते सामान्य आहे, परंतु स्प्रेडशीट डिझाइनद्वारे सपाट होत असताना, डेटाबेस संबंध असावा. 2D पासून 3D वर जाणे असे आहे.

सुदैवाने, पुनरावृत्ती होणारी क्षेत्रे सहसा शोधणे सोपे असते. या टेबलकडे पहा:

एखाद्या ऑर्डरमध्ये चार उत्पादने असतात तेव्हा काय होते? तीनपेक्षा जास्त उत्पादनांचे समर्थन करण्यासाठी आम्हाला दुसर्या फील्डची सारणी जोडणे आवश्यक आहे. आणि जर आपण इनपुट डेटाची मदत करण्यासाठी आपण टेबलभोवती क्लायंट ऍप्लिकेशन्स् तयार केले असेल, तर आम्हाला नवीन उत्पादन क्षेत्रासह काही बदल करावे लागेल. आणि आम्ही ऑर्डरमध्ये जेलीबीन्ससह सर्व ऑर्डर कसे शोधू? आपण टेबलमधील प्रत्येक प्रोडक्ट फिल्डला एस क्यू एल स्टेटमेंटसह विचारण्याची सक्ती केली जाऊ शकते जे खालील प्रमाणे दिसतील: SELECT * FROM PRODUCTS WHERE PRODUCT1 = 'Jelly Beans' किंवा Product2 = 'Jelly Beans' किंवा Product3 = 'Jelly Beans'.

सर्व माहिती एकत्र ठेवण्यासाठी एक टेबल ठेवण्याऐवजी, आपल्याकडे तीन तक्ता असला पाहिजे जे प्रत्येकाच्या माहितीचा वेगळा भाग धारण करतात. या उदाहरणामध्ये, ऑर्डरची माहिती, ऑर्डर आणि उत्पाद ऑर्डरची टॅब्लेट, जे उत्पादनांस ऑर्डरद्वारे जोडलेले आहे अशा सर्व उत्पादनांसह एक उत्पाद सारणीसह ऑर्डर तक्त्याची आवश्यकता आहे.

लक्षात घ्या की प्रत्येक टेबलचे स्वतःचे एकमेव ID फील्ड कसे आहे. ही प्राथमिक की आहे. आम्ही दुसर्या सारणीमध्ये परदेशी की म्हणून प्राथमिक की मूल्याचा वापर करून सारण्या जोडतो. प्राथमिक की आणि विदेशी की बद्दल अधिक वाचा

डेटाबेस चूक # 2: सारणीत एक टेबल एम्बेड करणे

ही आणखी एक सामान्य चूक आहे, परंतु ती नेहमी पुनरावृत्ती नसलेली क्षेत्रे म्हणून नेहमीच बाहेर पडू शकत नाही. डेटाबेस डिझाइन करताना, आपण हे सुनिश्चित करू इच्छित आहात की सर्व डेटा सारणीतील डेटा स्वतःच संबंधित आहे. हे वेगळे कसे आहे हे ओळखण्याबाबत त्या मुलाचे खेळ आहे. आपल्याकडे केळी, एक स्ट्रॉबेरी, आकाशी आणि एक टेलिव्हिजन सेट असेल तर कदाचित टेलिव्हिजन सेट कदाचित इतरत्रच असेल.

त्याच ओळींमध्ये, आपल्याकडे लोकांच्या विक्रीची टेबल्स असल्यास, त्या सारणीतील सर्व माहिती विशेषत: त्या विक्री व्यक्तीशी संबंधित असली पाहिजे. कोणतीही अतिरिक्त माहिती जी त्या विकिवर्याच्या व्यक्तीसाठी वेगळी नाही ती कदाचित आपल्या डेटाबेसमध्ये दुसरीकडे असेल.

हे सारणी कदाचित वैयक्तिक विक्रताशी संबंधित असेल असे दिसत असले तरी प्रत्यक्षात तक्ता टेबलमध्ये एम्बेड केलेला असतो. "ऑस्टिन डाउनटाउन" सह कार्यालय आणि कार्यालयीन नंबरची पुनरावृत्ती कशी होते ते पहा. कार्यालयीन फोन नंबर बदलल्यास काय होईल? माहितीचा एक भाग बदलण्यासाठी आपल्याला डेटाचा संपूर्ण संच अद्ययावत करावा लागेल, जे कधीही चांगली गोष्ट नाही हे फील्ड त्यांच्या स्वतःच्या टेबलवर हलविले पाहिजेत

या प्रकारचे डिझाईन आपल्याला ऑफिस टेबलमध्ये अतिरिक्त माहिती जोडण्याची क्षमता देते ज्यामुळे विक्री व्यक्ती टेबलमधील क्लेटरचा दुःस्वप्न तयार करता येतो. अशी कल्पना करा की हे सर्व मार्ग म्हणजे विक्रीचा पत्ता, शहर, राज्य आणि पिन कोड यांचा मागोवा ठेवणे हे सर्व माहिती विकिलिखित व्यक्तीच्या टेबलमध्ये!

डेटाबेस चूक # 3: सिंगल फील्डमध्ये माहिती दोन किंवा अधिक तुकडे टाकल्यावर

कार्यालयीन माहितीची विक्री व्यक्ती टेबलमध्ये जमा करणे त्या डेटाबेसशी फक्त एक समस्याच नाही. पत्ता फील्डमध्ये माहितीचे तीन भाग आहेत: मार्ग पत्ता, शहर आणि राज्य. डेटाबेसमधील प्रत्येक फिल्डमध्ये केवळ माहितीचा एक भाग असावा. जेव्हा आपल्याकडे एका फील्डमध्ये बहुविध माहिती आहे, तेव्हा माहितीसाठी डेटाबेससाठी क्वेरी करणे कठिण होऊ शकते.

उदाहरणार्थ, ऑस्टिनमधील सर्व विक्रीच्या लोकांना आम्ही एखादे प्रश्न विचारू इच्छित असल्यास काय? आपल्याला पत्ता फील्डमध्ये शोधण्याची गरज आहे, जे केवळ अकार्यक्षम नाही, परंतु चुकीची माहिती परत करू शकते. ओरेगॉनमधील पोर्टलंडमधील ऑस्टिन स्ट्रीटवर कोणी राहल्यास काय होईल?

सारणी कशी दिसावी ते येथे आहे:

येथे लक्षात ठेवण्यासाठी काही गोष्टी आहेत. प्रथम, "Address1" आणि "Address2" हे पुनरावृत्ती फील्ड चुकिच्या खाली येणे दिसत आहे.

तथापि, या प्रकरणात ते त्यांच्या स्वत: च्या टेबलमध्ये जाणाऱ्या डेटाच्या पुनरावृत्त गटाऐवजी थेट विक्री विभागाशी संबंधित असलेल्या माहितीच्या वेगवेगळ्या तुकड्यांना संदर्भ देत आहेत.

तसेच, बोनसची चूक टाळण्यासाठी, लक्षात घ्या की फोन नंबरचे स्वरूपन टेबलच्या बाहेर कसे सोडले गेले आहे. शक्य असेल तेव्हा आपण फील्डचे स्वरूप संचयित करू नये. फोन नंबरच्या बाबतीत, अनेक मार्गांनी लोक फोन नंबर लिहू शकतात: 215-555-5858 किंवा (215) 555-5858 यामुळे सेल्युलरला त्यांच्या फोन नंबरद्वारे किंवा त्याच क्षेत्र कोडमधील लोकांच्या शोधाचा शोध अधिक कठीण होऊ शकेल.

डेटाबेस चूक # 4: योग्य प्राथमिक की वापरत नाही

बर्याच उदाहरणांमध्ये, आपण आपल्या प्राथमिक किल्लीसाठी आपोआप वाढणारी संख्या किंवा काही व्युत्पन्न संख्या किंवा अक्षरांक वापरू इच्छित असाल. प्राथमिक की साठी आपण कोणतीही वास्तविक माहिती वापरणे टाळले पाहिजे तरीही तो एक चांगला अभिज्ञापक बनवेल असं वाटतं.

उदाहरणार्थ, आम्ही प्रत्येकाची स्वत: ची वैयक्तिक सुरक्षा क्रमांक असतो, त्यामुळे कर्मचारी डेटाबेससाठी सामाजिक सुरक्षा क्रमांक वापरणे ही चांगली कल्पना आहे. पण दुर्मिळ असतानाही सामाजिक सुरक्षा नंबर बदलण्याची शक्यता आहे, आणि आम्हाला आमच्या प्राथमिक की बदलण्याची इच्छा नाही.

वास्तविक माहिती एक कळ मूल्य वापरण्यामध्ये ही समस्या आहे. ते बदलू शकते.

डेटाबेस चूक # 5: नामकरण कराराचा वापर नाही

आपण आपल्या डेटाबेसची रचना प्रथम सुरू करता तेव्हा हे कदाचित मोठ्या कराराप्रमाणे ध्वनी नसेल परंतु माहिती मिळवण्यासाठी डेटाबेसवर लिहिल्या गेल्यानंतर नामकरण परंपरा येत असेल तर फील्डचे नाव लक्षात ठेवण्यात मदत होईल.

फक्त एका टेबलमध्ये FirstName, LastName आणि first_name, last_name सारख्या अन्य टेबलमध्ये नावे संग्रहित केली तर ती प्रक्रिया किती कठीण असेल याची कल्पना करा.

दोन सर्वात लोकप्रिय नामकरण नियमावली क्षेत्रातील प्रत्येक शब्दाचे पहिले अक्षर किंवा एक अंडरस्कोर वापरुन शब्द विभक्त करून कॅपिटल करते. आपण काही विकासकांना प्रथम शब्दास वगळून प्रत्येक शब्दाचे प्रथम अक्षर कॅप्चर करू शकतात: प्रथम नाव, lastName.

आपण एकेरी टेबल नावे किंवा बहुवचन सारणी नावे वापरण्याचा निर्णय घेऊ इच्छित असाल. ऑर्डरची टेबल किंवा ऑर्डर्स टेबल आहे का? तो एक ग्राहक टेबल किंवा ग्राहक टेबल आहे? पुन्हा, आपण ऑर्डर टेबल आणि एक ग्राहक टेबल सह अडकले जाऊ इच्छित नाही.

आपण निवडलेला नामांकन परंपरा खर्या अर्थाने निवडण्याआधीच नामकरण प्रथेनुसार टिकून राहण्यासारखी महत्त्वाची नाही.

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

अनुक्रमणिका मिळविणे ही योग्य गोष्टींपैकी एक आहे, विशेषत: त्या डेटाबेस डिझाइनमध्ये त्या नवीनसाठी. सर्व प्राथमिक की आणि परदेशी कळी अनुक्रमित व्हाव्यात. या सारख्या लिंक सारणी एकत्रित केल्या जातात, त्यामुळे निर्देशांशिवाय, आपण आपल्या डेटाबेसमधून अत्यंत खराब कामगिरी पाहू शकाल.

पण जे अनेकदा सुटल्या जातात ते इतर क्षेत्रही असतात. हे "WHERE" फील्ड आहेत. जर आपण अनेकदा WHERE कलमातील फील्डचा वापर करून आपला शोध कमी करू इच्छित असाल तर आपण त्या क्षेत्रावरील निर्देशांक टाकण्याबद्दल विचार करू इच्छित असाल. तथापि, आपण सारणीचे सारखा निर्देशित करू इच्छित नाही, जे कार्यप्रदर्शन देखील दुखवू शकते.

निर्णय कसा करावा? हे डेटाबेस डिझाईन कला एक भाग आहे. आपण सारणीवर किती अनुक्रमित करावे त्यावरील कोणतीही कठोर मर्यादा नाही. प्रामुख्याने, आपण WHERE कलमामध्ये वारंवार वापरले जाणारे कोणतेही क्षेत्र इंडेक्स करू इच्छित आहात. आपल्या डेटाबेसचे व्यवस्थित अनुक्रमित करण्याबद्दल अधिक वाचा.