एंटीपैटर्न?
सामान्य स्थिति में, दूसरी तालिका एंटी-पैटर्न है डेटाबेस डिजाइन के संदर्भ में। और, इससे भी अधिक, इसका विशिष्ट नाम है:इकाई-विशेषता-मूल्य (ईएवी)। कुछ मामले हैं, जब इस डिजाइन का उपयोग करना उचित है, लेकिन यह दुर्लभ मामले हैं - और वहां भी इसे टाला जा सकता है।
ईएवी खराब क्यों है
डेटा अखंडता समर्थन
इस तथ्य के बावजूद कि ऐसी संरचना अधिक "लचीली" या "उन्नत" लगती है, इस डिजाइन में कमजोरी है।
- अनिवार्य विशेषताओं को बनाना असंभव है . आप कुछ विशेषता को अनिवार्य नहीं बना सकते, क्योंकि विशेषता अब एक पंक्ति के रूप में संग्रहीत है - और एकमात्र संकेत है कि विशेषता सेट नहीं है - यह है कि संबंधित पंक्ति तालिका में अनुपस्थित है। SQL आपको इस तरह की बाधा को मूल रूप से बनाने की अनुमति नहीं देगा - इस प्रकार, आपको इसे आवेदन में जांचना होगा - और, हाँ, हर बार अपनी तालिका से पूछताछ करें
- डेटा प्रकारों का मिश्रण . आप SQL मानक डेटा प्रकारों का उपयोग करने में सक्षम नहीं होंगे। क्योंकि आपका मान कॉलम इसमें सभी संग्रहीत मानों के लिए "सुपर-टाइप" होना चाहिए। इसका मतलब है - आपको सामान्य रूप से सभी डेटा को कच्चे तार . के रूप में संग्रहीत करना होगा . फिर आप देखेंगे कि तार के साथ तारीखों के साथ काम करना कितना दर्दनाक है, हर बार डेटा प्रकार कास्टिंग करना, डेटा अखंडता की जांच करना, आदि।
- संदर्भात्मक सत्यनिष्ठा को लागू करना असंभव है . सामान्य स्थिति में, आप अपने मूल्यों को उन तक सीमित करने के लिए विदेशी कुंजी का उपयोग कर सकते हैं, जिन्हें मूल तालिका में परिभाषित किया गया है। लेकिन इस मामले में नहीं - ऐसा इसलिए है क्योंकि तालिका में प्रत्येक पंक्ति पर संदर्भात्मक अखंडता लागू होती है, लेकिन पंक्ति मानों के लिए नहीं। तो - आप इस लाभ को खो देंगे - और यह मौलिक में से एक . है डीबी के संबंध में
- विशेषताओं के नाम सेट करना असंभव है . इसका मतलब है - आप डीबी स्तर पर विशेषता नाम को ठीक से प्रतिबंधित नहीं कर सकते हैं। उदाहरण के लिए, आप
"customer_name". लिखेंगे पहले मामले में विशेषता नाम के रूप में - और दूसरा डेवलपर इसे भूल जाएगा और"name_of_customer"का उपयोग करेगा . और.. ठीक है, DB उसे पास कर देगा और आप इस मामले को डीबग करने में बिताए घंटों के साथ समाप्त हो जाएंगे।
पंक्ति पुनर्निर्माण
इसके अलावा, सामान्य स्थिति में पंक्ति पुनर्निर्माण भयानक होगा। यदि आपके पास, उदाहरण के लिए, 5 विशेषताएँ हैं - जो कि 5 स्व-तालिका होंगी JOIN -एस। इस तरह के सरल के लिए बहुत बुरा - पहली नज़र में - मामला। इसलिए मैं यह कल्पना भी नहीं करना चाहता कि आप 20 विशेषताओं को कैसे बनाए रखेंगे।
क्या इसे उचित ठहराया जा सकता है?
मेरी बात है - नहीं। RDBMS में इससे बचने का एक तरीका हमेशा रहेगा। यह भयंकर है। और अगर ईएवी का उपयोग करने का इरादा है, तो सबसे अच्छा विकल्प गैर-संबंधपरक हो सकता है डेटाबेस।
