नहीं, यह एक रिलेशनल डेटाबेस के लिए एक खराब डिज़ाइन है। यह Entity-Attribute-Value का एक उदाहरण है डिजाईन। यह लचीला है, लेकिन यह संबंधपरक डेटाबेस होने के अर्थ के अधिकांश नियमों को तोड़ता है।
लचीले डेटाबेस के समाधान के रूप में ईएवी डिज़ाइन में उतरने से पहले, इस कहानी को पढ़ें:खराब कारमा .
अधिक विशेष रूप से, ईएवी के साथ कुछ समस्याओं में शामिल हैं:
- आप नहीं जानते कि किसी दिए गए ID_NUM के लिए क्वेरी किए बिना कौन-सी विशेषताएँ मौजूद हैं।
- आप NOT NULL के समकक्ष किसी भी विशेषता को अनिवार्य नहीं बना सकते।
- आप डेटाबेस बाधाओं का उपयोग नहीं कर सकते।
- आप SQL डेटा प्रकारों का उपयोग नहीं कर सकते;
valueकॉलम एक लंबा VARCHAR होना चाहिए। - विशेष रूप से MySQL में, प्रत्येक VARCHAR अपने स्वयं के डेटा पृष्ठ पर संग्रहीत होता है, इसलिए यह बहुत बेकार है।
जब आप ईएवी डिज़ाइन का उपयोग करते हैं तो प्रश्न भी अविश्वसनीय रूप से जटिल होते हैं। मैगेंटो, एक ओपन-सोर्स ईकॉमर्स प्लेटफॉर्म, ईएवी का व्यापक रूप से उपयोग करता है, और कई उपयोगकर्ता कहते हैं कि यदि आपको कस्टम रिपोर्ट की आवश्यकता है तो यह बहुत धीमा और क्वेरी करना कठिन है।
संबंधपरक होने के लिए, आपको प्रत्येक भिन्न विशेषता को उसके अपने कॉलम में, उसके अपने नाम और उपयुक्त डेटाटाइप के साथ संग्रहित करना चाहिए।
मैंने अपनी प्रस्तुति में ईएवी के बारे में अधिक लिखा है व्यावहारिक वस्तु-उन्मुख SQL में मॉडल और मेरे ब्लॉग पोस्ट में EAV FAIL , और मेरी पुस्तक में, SQL एंटीपैटर्न:डेटाबेस प्रोग्रामिंग के नुकसान से बचना ।
