अतिरिक्त फ़ील्ड इकाई के लिए इष्टतम डीबी संरचना

Question

मेरे पास एक डीबी (पोस्टग्रेर्स आधारित) में एक टेबल है, जो ऑब्जेक्ट उन्मुख प्रोग्रामिंग में सुपरक्लास की तरह कार्य करती है। इसमें एक स्तंभ 'प्रकार' है जो निर्धारित करता है, तालिका में कौन से अतिरिक्त कॉलम मौजूद होना चाहिए (उप-वर्ग गुण)। लेकिन मैं नहीं चाहता कि तालिका में सभी संभावित कॉलम (सभी संभावित प्रकारों के सभी गुण) शामिल हों।

इसलिए मैंने 'कुंजी' और 'मान' कॉलम (यानी 'filename' = '/ file', या 'some_value' = '5') को containg, एक तालिका बनाने का निर्णय लिया, जिसमें किसी भी संभावित संपत्ति शामिल है ऑब्जेक्ट, सुपरक्लास टेबल में शामिल नहीं है। और उपलब्ध 'कुंजी' मानों को रखने के लिए एक संबंधित तालिका भी बनाई।

लेकिन इस तरह के आर्किटेक्चर में कोई समस्या है - कुछ भी शामिल करने में सक्षम होने के लिए 'मान' कॉलम डिफ़ॉल्ट रूप से एक स्ट्रिंग डेटा प्रकार का होना चाहिए। लेकिन मुझे नहीं लगता कि स्ट्रिंग्स में और से कनवर्ट करना एक अच्छा निर्णय है। इस सीमा को बाईपास करने का सबसे अच्छा तरीका क्या है?

Answer 1

जिस डिजाइन के साथ आप प्रयोग कर रहे हैं वह Entity-Attribute-Value की भिन्नता है, और यह पूरी तरह से समस्याओं और अक्षमताओं के साथ आता है। अंतिम उपाय के अलावा, आप जो भी कर रहे हैं उसके लिए यह एक अच्छा समाधान नहीं है।

क्या बेहतर समाधान हो सकता है जो गिर गया 888 वर्णन करता है: अपने प्रत्येक उपप्रकारों के लिए "उप प्रकार" तालिका बनाएं। यह ठीक है अगर आपके पास उपप्रकारों की सीमित संख्या है, जो आपके जैसा लगता है। फिर यदि आपके उप-विशिष्ट विशेषताओं में डेटा प्रकार हो सकते हैं, और यदि उपयुक्त हो तो NOT NULL बाधा भी हो सकती है, यदि आप ईएवी डिज़ाइन का उपयोग करते हैं तो असंभव है।

सबटाइप-टेबल डिज़ाइन की एक शेष कमजोरी यह है कि आप उपप्रकार तालिका में मौजूद पंक्ति को लागू नहीं कर सकते हैं क्योंकि सुपरक्लास तालिका में मुख्य पंक्ति यह कहती है। लेकिन यह ईएवी डिजाइन द्वारा पेश की गई तुलना में हल्की कमजोरी है।

संपादित करें: टिप्पणी-से-किसी भी इकाई के बारे में आपकी अतिरिक्त जानकारी के बारे में, हाँ यह एक बहुत ही सामान्य पैटर्न है। "पॉलिमॉर्फिक एसोसिएशन" नामक एक टूटे हुए समाधान से सावधान रहें, जो इस तकनीक में कई लोगों का उपयोग करने वाली तकनीक है।

Answer 2

केवल वैकल्पिक हल (जबकि अपनी strucure को बनाए रखना) अलग-अलग तालिकाओं के लिए है कुंजी-मूल्य तालिका में एकाधिक कॉलम होते हैं, प्रत्येक डेटा प्रकार के लिए, यानी स्ट्रिंगवैल्यू, डेसिमल वैल्यू, आदि

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

Answer 3

एक आम दृष्टिकोण होने है

create table IntProps(...); 
create table StringProps(...); 
create table CurrencyProps(...); 

लेकिन मुझे नहीं लगता कि यह एक अच्छा विचार है कि ...:

Answer 4

इसके बजाय इसके बारे में ... प्रत्येक उप-प्रकार की अपनी डीबी तालिका प्राप्त होती है। और आधार/सुपर टेबल में केवल एक वर्चर कॉलम होता है जिसमें उप-प्रकार डीबी तालिका का नाम होता है। तो फिर तुम कुछ इस तरह हो सकता है ...

Entity 
------ 
ID 
Name 
Type 
SubTypeName (value of this column will be 'Dog') 


Dog 
--- 
VetName 
VetNumber 
etc 

आप आधार तालिका में varchar मूल्यों होने के लिए अपने (उप) तालिका नाम नहीं करना चाहते हैं, तो आप भी सिर्फ एक उपप्रकार तालिका जिसका प्राथमिक कुंजी हो सकता है आधार तालिका में होगा।

Answer 5

आपके पास एक प्रति प्रकार कुंजी/मूल्य तालिका हो सकती है। उपलब्ध तालिका को सही टाइप की गई कुंजी/मान तालिका को इंगित करने के लिए किसी विशिष्ट कुंजी/प्रकार जोड़ी की उपलब्धता को एन्कोड करने की आवश्यकता होगी।

हालांकि यह एक पंक्ति आधारित संबंधपरक डेटाबेस के लिए एक अत्यधिक अक्षम वास्तुकला की तरह लगता है।

शायद आपको कॉलम उन्मुख संबंधपरक डेटाबेस पर नज़र डालना चाहिए?

Answer 6

उत्तर के लिए धन्यवाद। मैं थोड़ी अधिक विशेष रूप से समझाऊंगा जो मुझे चाहिए। ब्लॉग + फोरम वेबसाइट प्रोग्राम करने की आवश्यकता है, और मैं WordPress DB structure देख रहा हूं।

किसी भी प्रकार की 'ऑब्जेक्ट', जैसे ब्लॉग एंट्री, या वीडियो फ़ाइल अटैचमेंट पर टिप्पणियां रखने की क्षमता की एक मजबूत आवश्यकता है। उपरोक्त डीबी संरचना को स्केल करना बहुत आसान है और हमारी सभी जरूरतों को पूरा करने के लिए इसकी पसंद का कारण था।

लेकिन इसे बदलने में देर नहीं हुई है, क्योंकि यह प्रारंभिक इंजीनियरिंग के चरण में है। इसके अलावा हमारा मॉडल अब पूरी तरह पेड़-पदानुक्रम आधारित डीबी की तरह गंध करता है। अभी के लिए मैं Bill Karwin's and fallen888 answers स्वीकार करूंगा, लेकिन शायद मैं पूरी तरह से गलत दिशा में जा रहा हूं?

मैं इन सभी लोगों को टिप्पणी करने की प्रशंसा:

Answer 7

उपयोगकर्ता मेज पर एक नए क्षेत्र को जोड़ने में सक्षम होने के बारे में

।

मुझे कुछ साल पहले इस तरह की चीज़ में दिलचस्पी थी, लेकिन हाल ही में थोड़ा कोड लिखा है (PHP और MYSQL के अलावा)।

मुझे लगता है कि अगर आप जारी रखना चाहते हैं तो यह ठीक है - आप कुछ नया कर सकते हैं।

योजना पर किसी भी ठंडे पानी को डालने के लिए खेद है - मैं आपके प्रयासों की प्रशंसा करता हूं। मेरी व्यक्तिगत धारणा यह है कि यदि आप इस दिशा में काफी दूर जाते हैं, तो आप एक ऐसे सिस्टम के साथ समाप्त हो जाएंगे जो एसक्यूएल की तुलना में अधिक प्राकृतिक भाषा का अर्थ लेता है। (लगभग 1 9 70 में, एसक्यूएल को वास्तव में सेक्वेल लिखा गया था, और यह वास्तव में "संरचित अंग्रेजी क्वेरी भाषा" के लिए खड़ा था, लेकिन 1 9 70 के दशक में इसे मानकीकृत करने के बाद - मुझे लगता है कि किसी ने कहा था कि ओरेकल पहला व्यावसायिक कार्यान्वयन था, 1 9 07, "अंग्रेजी" गिरा दिया गया, क्योंकि मुझे लगता है कि उन्होंने फैसला किया कि यह केवल अंग्रेज़ी का एक छोटा सबसेट था।

मैं इस क्षेत्र में भाप से बाहर चला गया हूं, क्योंकि मुझे नौकरी नहीं मिली है। बिना किसी आसान नौकरी के बिलों का भुगतान किया जाता है, जहाँ मैं इन विचारों के साथ प्रयोग कर सकते हैं, यह सब करने के लिए एक सा मुश्किल से इस क्षेत्र पर ध्यान केंद्रित करने के लिए।

शुभकामनाएं।

Answer 8

माफ करना, मैं 19079 से ऊपर लिखा है, मैं मतलब साल 1979 ओरेकल अपने पहले अनुबंध रिट मिला सीआईए के लिए एक डेटाबेस में आईएनजी।