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

यह लेख डीबी सामान्यीकरण के बारे में नहीं है। यदि आप इसे सीखना चाहते हैं, तो यहां मैंने आपको मूल बातें बताई हैं।

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

CamelCase नामकरण या अंडरस्कोर?

मैं लगातार डेटाबेस में आता हूं जिसमें टेबल का नाम CustomerOrders या customer_orders की शैली में रखा गया है। कौन सा उपयोग करना बेहतर है? शायद आप पहले से ही स्थापित मानक को लागू करना चाहते हैं, लेकिन यदि आप एक नया डेटाबेस बना रहे हैं, तो मैं पहुंच बढ़ाने के लिए अंडरस्कोर का उपयोग करने की सलाह देता हूं। "अंडरवैल्यू" की तुलना में "अंडर वैल्यू" वाक्यांश का एक अलग अर्थ है, लेकिन एक अंडरस्कोर के साथ, पहला हमेशा under_value , और दूसरा undervalue होगा। और CamelCase का उपयोग करते समय हमें Undervalue और UnderValue मिलता है, जो केस-असंवेदनशील एसक्यूएल के समान हैं। इसके अलावा, यदि आपको दृष्टि संबंधी समस्याएं हैं और शब्दों पर जोर देने के लिए लगातार हेडसेट और पिन का प्रयोग कर रहे हैं, तो अंडरलाइनिंग को पढ़ना बहुत आसान है।

अंत में, CamelCase उन लोगों के लिए पढ़ना मुश्किल है जिनके लिए अंग्रेजी मूल नहीं है।
संक्षेप में, यह एक सख्त सिफारिश नहीं है, बल्कि व्यक्तिगत प्राथमिकता है।

तालिका नामों में बहुवचन या एकवचन?

डेटाबेस सिद्धांत विशेषज्ञ लंबे समय से इस बात पर बहस कर रहे हैं कि तालिकाओं को एकवचन (ग्राहक) या बहुवचन (ग्राहक) होना चाहिए या नहीं। मुझे इस गॉर्डियन गाँठ को सिद्धांत में गहराई से जाने के बिना काट दें, बस व्यावहारिकता की मदद से: बहुवचन तालिका के नाम आरक्षित खोजशब्दों के साथ संघर्ष की संभावना कम है।

क्या आपके पास उपयोगकर्ता - users ? SQL में user कीवर्ड है। क्या आपको एक बाधा तालिका की आवश्यकता है? constraint एक आरक्षित शब्द है। audit शब्द
आरक्षित है, लेकिन क्या आपको audit टेबल की आवश्यकता है? बस संज्ञाओं के बहुवचन रूप का उपयोग करें, और फिर अधिकांश आरक्षित शब्द आपको SQL में परेशान नहीं करेंगे। यहां तक कि PostgreSQL, जिसमें एक उत्कृष्ट SQL पार्सर है, user तालिका पर ठोकर खाई है।

बस बहुवचन का उपयोग करें, और संघर्ष की संभावना बहुत कम होगी।

"आईडी" के रूप में आईडी के साथ कॉलम का नाम न दें

मैंने खुद वर्षों से पाप किया है। एक बार जब मैंने पेरिस में एक क्लाइंट के साथ काम किया, और डीबीए ने मेरे बारे में शिकायत की जब मैंने id कॉलम को नाम id । मुझे लगा कि वह सिर्फ एक पेडेंट है। वास्तव में, स्तंभ नाम customers.id अद्वितीय है, और customers.customer_id जानकारी की पुनरावृत्ति है।

और बाद में मुझे यह डिबग करना पड़ा:

 SELECT thread.* FROM email thread JOIN email selected ON selected.id = thread.id JOIN character recipient ON recipient.id = thread.recipient_id JOIN station_area sa ON sa.id = recipient.id JOIN station st ON st.id = sa.id JOIN star origin ON origin.id = thread.id JOIN star destination ON destination.id = st.id LEFT JOIN route ON ( route.from_id = origin.id AND route.to_id = destination.id ) WHERE selected.id = ? AND ( thread.sender_id = ? OR ( thread.recipient_id = ? AND ( origin.id = destination.id OR ( route.distance IS NOT NULL AND now() >= thread.datesent + ( route.distance * interval '30 seconds' ) )))) ORDER BY datesent ASC, thread.parent_id ASC

समस्या पर ध्यान दें? यदि SQL ने पूर्ण आईडी नामों का उपयोग किया है, जैसे कि email_id , star_id या station_id , तो कीड़े तुरंत बाहर निकल जाएंगे क्योंकि मैंने यह कोड लिखा था , और बाद में नहीं, जब मैंने यह समझने की कोशिश की कि मैंने क्या गलत किया।

अपने आप को एक एहसान करो और आईडी के लिए पूर्ण नामों का उपयोग करें। बाद में धन्यवाद।

स्तंभ नाम

कॉलम को यथासंभव वर्णनात्मक नाम दें। मान लें कि temperature कॉलम का इससे कोई लेना-देना नहीं है:

 SELECT name, 'too cold' FROM areas WHERE temperature < 32;

मैं फ्रांस में रहता हूं, और हमारे लिए 32 डिग्री का तापमान "बहुत ठंडा" होगा। इसलिए, fahrenheit कॉलम का नाम देना बेहतर है।

 SELECT name, 'too cold' FROM areas WHERE fahrenheit < 32;

अब सब कुछ पूरी तरह से स्पष्ट है।

यदि आपके पास विदेशी कुंजी प्रतिबंध हैं, तो जब भी संभव हो प्रतिबंध के दोनों किनारों पर कॉलम को एक ही नाम दें। यहाँ एक पूरी तरह से सोचा, उचित SQL है:

 SELECT * FROM some_table s JOIN some_other_table o ON o.owner = s.person_id;

यह कोड वास्तव में ठीक है। लेकिन जब आप तालिका की परिभाषा को देखते हैं, तो आप देखेंगे कि some_other_table.owner पास some_other_table.owner के साथ एक विदेशी कुंजी बाधा है। तो अनिवार्य रूप से यह SQL गलत है। समान नामों का उपयोग करना आवश्यक था:

 SELECT * FROM some_table s JOIN some_other_table o ON o.company_id = s.person_id;

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

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

यह भी ध्यान दें कि उपरोक्त उदाहरण में, owner company_id से बेहतर उद्देश्य का वर्णन company_id । यदि यह आपको भ्रमित करने वाला लगता है, तो आप owning_company_id के owning_company_id कॉलम का नाम दे सकते हैं। फिर नाम आपको कॉलम का उद्देश्य बताएगा।

फुल वैल्यू से बचें

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

डेटाबेस के प्रकार

डेटाबेस में विभिन्न प्रकार के डेटा हो सकते हैं: INTEGER, JSON, DATETIME, इत्यादि प्रकार स्तंभ के साथ जुड़ा हुआ है और इसमें जोड़ा गया कोई भी मान इस प्रकार के अनुरूप होना चाहिए।

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

 CustomerAccount.java:5: error: bad operand types for binary operator '>' if ( current > threshold ) { ^ first type: String second type: int

यहां तक कि अगर आप नोटिस नहीं करते हैं कि current > threshold अतुलनीय प्रकारों की तुलना करता है, तो कंपाइलर आपके लिए इसे पकड़ लेगा।

विडंबना यह है कि, डेटाबेस जो आपके डेटा को स्टोर करते हैं - और डेटा भ्रष्टाचार के खिलाफ आपकी रक्षा की अंतिम पंक्ति है - प्रकारों के साथ बहुत काम करते हैं! बस घृणित है। उदाहरण के लिए, यदि आपके customers तालिका में सरोगेट कुंजी है, तो आप यह कर सकते हैं:

 SELECT name, birthdate FROM customers WHERE customer_id > weight;

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

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

और फिर NULL मान दृश्य पर दिखाई देते हैं। SQL मानक ने उन्हें केवल एक ही स्थान पर IS NULL और IS NOT NULL । चूंकि NULL मान परिभाषा से अज्ञात है, इसलिए आपके पास इसके लिए डिज़ाइन किए गए ऑपरेटर नहीं हो सकते। और इसलिए IS NULL और IS NOT NULL बजाय = NULL और != NULL । और NULL मान की किसी भी तुलना में एक नया NULL मान प्रकट होता है।

यदि यह आपको अजीब लगता है, तो यह बहुत आसान होगा यदि आप NULL के बजाय "अज्ञात" लिखते हैं:

~~NULL~~ अज्ञात मानों की तुलना करने से ~~NULL~~ अज्ञात मान प्राप्त होते हैं।

हाँ, अब मैं देख रहा हूँ!

अशक्त मूल्य का क्या अर्थ है?

सिद्धांत के टुकड़ों के साथ सशस्त्र, हम इसके व्यावहारिक परिणामों पर विचार करते हैं।

आपको उन सभी कर्मचारियों को $ 500 का बोनस देना होगा, जिनकी साल भर की तनख्वाह $ 50 हजार से अधिक है। आप यह कोड लिखते हैं:

 SELECT employee_number, name FROM employees WHERE salary > 50000;

और आप बस निकाल दिए गए, क्योंकि आपके बॉस ने $ 50 हजार से अधिक कमाए, लेकिन उनका वेतन डेटाबेस में नहीं है ( employees.salary कॉलम कॉलम NULL है), और तुलना ऑपरेटर 50 000 के साथ NULL की तुलना नहीं कर सकता है।

इस कॉलम में NULL क्यों है? हो सकता है कि वेतन गोपनीय हो। शायद सूचना अभी तक नहीं आई है। शायद यह एक सलाहकार है और भुगतान नहीं करता है। हो सकता है कि उसके पास प्रति घंटा वेतन हो, न कि वेतन। डेटा गायब होने के कई कारण हो सकते हैं।

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

और हाँ, यह एक मूर्खतापूर्ण उदाहरण था, लेकिन यह आखिरी तिनका था।

पूर्ण मान तार्किक रूप से असंभव स्थितियों की ओर ले जाते हैं

यह आपको लग सकता है कि मैं NULL मूल्यों के संबंध में पांडित्य हूं। हालांकि, आइए एक और उदाहरण देखें जो वास्तविकता के बहुत करीब है।

कुछ साल पहले, मैंने लंदन में एक डोमेन रजिस्ट्रार के लिए काम किया और यह समझने की कोशिश की कि 80-लाइन वाली SQL क्वेरी गलत डेटा क्यों देती है। उस स्थिति में, जानकारी निश्चित रूप से वापस आनी चाहिए थी, लेकिन ऐसा नहीं हुआ। मुझे स्वीकार करने में शर्म आती है, लेकिन मुझे यह समझने में एक दिन लगा कि कारण ऐसी स्थितियों का संयोजन था:

मैंने OUTER JOIN का इस्तेमाल किया।
वे आसानी से NULL मान उत्पन्न कर सकते थे।
गलत मानों के कारण SQL गलत उत्तर दे सकता है।

कई डेवलपर्स बाद के पहलू से अवगत नहीं हैं, तो आइए डेटाबेस इन डेप्थ नामक पुस्तक से एक उदाहरण देखें। दो तालिकाओं का एक सरल आरेख:

suppliers

supplier_id	शहर
एस 1	लंडन

parts

part_id	शहर
p1	शून्य

एक सरल उदाहरण खोजना मुश्किल है।

यह कोड p1 देता है।

 SELECT part_id FROM parts;

यह कोड क्या करेगा?

 SELECT part_id FROM parts WHERE city = city;

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

 SELECT s.supplier_id, p.part_id FROM suppliers s, parts p WHERE p.city <> s.city OR p.city <> 'Paris';

हमें जवाब में एक तार नहीं मिला, क्योंकि हम शहर NULL ( p.city ) की तुलना नहीं कर सकते हैं, और इसलिए WHERE की शाखाओं में से कोई भी true ।

हालाँकि, हम जानते हैं कि अज्ञात शहर या तो पेरिस है या नहीं। यदि यह पेरिस है, तो पहली शर्त सच होगी ( <> 'London' )। यदि यह पेरिस नहीं है, तो दूसरी शर्त सही होगी ( <> 'Paris' )। इस प्रकार, WHERE true होना चाहिए, लेकिन यह नहीं है, और परिणामस्वरूप, SQL एक तार्किक रूप से असंभव परिणाम उत्पन्न करता है।

यह एक बग था जिसका मैंने लंदन में सामना किया। हर बार जब आप SQL लिखते हैं जो NULL मान उत्पन्न कर सकता है या कर सकता है, तो आप एक गलत परिणाम प्राप्त करने का जोखिम चलाते हैं। यह अक्सर होता है, लेकिन इसे पहचानना बहुत मुश्किल है।

परिणाम

CamelCase बजाय __ उपयोग करें।
तालिका नाम बहुवचन में होना चाहिए।
आइडेंटिफ़ायर वाले क्षेत्रों के लिए विस्तारित नाम दें ( id बजाय item_id )।
अस्पष्ट कॉलम नामों से बचें।
यदि संभव हो, तो स्तंभों को उसी तरह से विदेशी कुंजी के साथ नाम दें, जिस स्तंभ को वे संदर्भित करते हैं।
जब भी संभव हो, सभी कॉलम परिभाषाओं में NULL को न जोड़ें।
जब भी संभव हो, SQL लिखने से बचें जो NULL मान उत्पन्न कर सके।

हालांकि सही नहीं है, यह डेटाबेस डिज़ाइन गाइड आपके जीवन को आसान बना देगा।

डेटाबेस डिजाइन मानक