क्यों? सबकरें आपकी संस्थाओं को इस तरह से एक्स्टेंसिबल होने की आवश्यकता है? शायद नहीं -- अधिकांश अनुप्रयोगों में अधिकतम एक या दो इकाइयाँ हैं जो लचीलेपन के इस स्तर से लाभान्वित होंगी। अन्य संस्थाएं वास्तव में नहीं . की स्थिरता और स्पष्टता से लाभान्वित होती हैं हर समय बदल रहा है।
EAV आंतरिक-प्लेटफ़ॉर्म प्रभाव का एक उदाहरण है :
दूसरे शब्दों में, अब यह आपकी जिम्मेदारी है कि आप उन सभी चीजों को करने के लिए एप्लिकेशन कोड लिखें जो एक उचित RDBMS पहले से ही प्रदान करता है, जैसे कि बाधाएं और डेटा प्रकार। यहां तक कि एक कॉलम को अनिवार्य बनाना जितना आसान है जैसे NOT NULL ईएवी में काम नहीं करता।
यह सच है कि कभी-कभी किसी प्रोजेक्ट के लिए बहुत सी तालिकाओं की आवश्यकता होती है। लेकिन आप खुद को बेवकूफ बना रहे हैं अगर आपको लगता है कि आपने सिर्फ दो टेबल बनाकर प्रोजेक्ट को सरल बना दिया है। आपके पास अभी भी उतनी ही अलग-अलग संस्थाएं होंगी जितनी आपके पास होतीं, लेकिन अब यह आप पर निर्भर है कि आप उन्हें कचरे के ढेर में बदलने से रोकें।
इससे पहले कि आप ईएवी में बहुत अधिक समय निवेश करें, इस कहानी को एक ऐसी कंपनी के बारे में पढ़ें जो लगभग काम करना बंद कर देती है क्योंकि किसी ने अपने डेटा भंडार को मनमाने ढंग से लचीला बनाने की कोशिश की:खराब कारमा ।
मैंने ब्लॉग पोस्ट में ईएवी के बारे में और भी लिखा, EAV FAIL , और मेरी पुस्तक के एक अध्याय में, SQL एंटीपैटर्न:डेटाबेस प्रोग्रामिंग के नुकसान से बचना ।
