अच्छा डेटाबेस डिज़ाइन, गुणों की चर संख्या

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

मैं संभव समाधान और मेरी प्रारंभिक विचार उन पर निम्नलिखित के साथ आ गया है:

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

मैं के रूप में मैं यहाँ जाना है, इस समस्या से संबंधित किसी भी लिंक या "अवश्य पढ़ें" डेटाबेस डिजाइन पर लेख की सराहना की जाएगी तो मैं सीख रहा हूँ डेटाबेस के साथ बहुत अनुभव नहीं है। धन्यवाद!

संपादित करें: सबसे पहले, मुझे पता चला कि मुझे Google "विरासत मानचित्रण" की आवश्यकता है, जो किसी और के समान प्रश्न पूछने में मदद कर सकता है। समस्या को हल करने के लिए मैंने # 2 और # 3 के संकर का उपयोग करके समाप्त किया। यह वास्तव में बहुत आसान था, अच्छी तरह से काम करता है, और ईएवी की जटिलता के बिना अतिरिक्त उपकरण प्रकार जोड़ने की समस्या हल करता है। सभी टिप्पणियों और सुझावों के लिए धन्यवाद!

स्रोत

2012-07-21 neurotik

निम्नलिखित पोस्ट में जवाब चेक करें: http://stackoverflow.com/questions/870808/entity-attribute-value-database-vs-strict-relational-model-commerce-question –

यह पोस्ट कुछ अन्य लेखों के विपरीत है I पढ़ना पढ़ना ईएवी से बचा जाना चाहिए, किसी को भी विचार? – neurotik

विकल्प 1, 2, और 3 एक बहुत ही गंभीर दोष साझा करते हैं: जब आप कोई नई विशेषता का सपना देखते हैं तो आपको अंतर्निहित तालिका स्कीमा को संशोधित करना होगा। विकल्प 1 के मामले में समस्या इस संभावना से जटिल है कि एक नया उपकरण प्रकार पेश किया जाएगा। आप कितने निश्चित हैं कि गुणों का सेट हर समय तय किया गया है?आप आउटेज लेने या क्लाइंट को बताने में कितना खुश होंगे कि नहीं, आपके पास कोई नई विशेषता नहीं हो सकती है?

यदि आप सामान्य विशेषताओं से पूछताछ करने की संभावना रखते हैं, तो आप उपकरण प्रकार के बजाए विशेषता प्रकार पर विभाजन में फेंकने वाले 2 के डैश के साथ 3 और 4 के संकर का प्रयास कर सकते हैं, जो अधिक अस्थिर लगता है। विकल्प 4, अगर मैं सही ढंग से समझता हूं, तो विकल्प 1 का एक सामान्य रूप संस्करण है जो इसकी सभी अंतर्निहित समस्याओं (स्पैरनेस और ब्रितलनेस) को हल करता है।

INVENTORY(id*, model, manufacturer, serial) 
ATTRIBUTE(id*, name, type, description) 
INVENTORY_FACT_STRING(inv_id*, attr_id*, value) 
INVENTORY_FACT_NUMBER(inv_id*, attr_id*, value) 
INVENTORY_FACT_LIST_STRING(inv_id*, attr_id*, ordinal*, value)

आदि

स्रोत

2012-07-21 04:10:13

नए उपकरण पेश किए जा रहे हैं निश्चित रूप से, कोई व्यक्ति वास्तव में एक विशेषता जोड़ने के इच्छुक व्यक्ति की संभावना नहीं है, लेकिन संभव है। आउटेज एक समस्या नहीं है, लेकिन यह कहकर कि नए गुणों को जोड़ा नहीं जा सकता है क्योंकि नए उपकरणों को जोड़ने में सक्षम होना चाहिए और मैं निश्चित रूप से यह नहीं कह सकता कि वर्तमान विशेषताओं में सभी भविष्य के मामलों को शामिल किया जाएगा। – neurotik

यह ईएवी की तरह बहुत लगता है। डरो नहीं! –

वाह, यहां हर किसी से ईएवी का जबरदस्त समर्थन। मुझे उम्मीद नहीं थी, आश्चर्यजनक है कि आपके शोध की शुरुआत में कुछ नकारात्मक लेख वास्तव में आपको ट्रैक से फेंक सकते हैं! मैं इसे जाने दूंगा। सबको धन्यवाद! – neurotik

किसी भी SQL डेटाबेस के लिए हल करना मुश्किल समस्या है। MySQL के लिए कोई अच्छा जवाब नहीं है।

1) काम करता है और आप महत्वपूर्ण उपकरण प्रकारों के लिए कुछ विचार जोड़ सकते हैं। यह संख्या में शामिल हो जाता है और प्रत्येक फ़ील्ड पर क्वेरी और इंडेक्स की अनुमति देता है।

2) आप सभी प्रश्नों को एक संघ का उपयोग कर सकते हैं। PostgreSQL और इनफॉर्मिक्स में टेबल विरासत है।

3) यह अक्सर कार्यान्वयन विकल्प होता है। फिर, आप जुड़ने के लिए विचारों का उपयोग कर सकते हैं।

4) पोस्टग्रेएसक्यूएल, इनफॉर्मिक्स, ओरेकल, आईबीएम डीबी 2 और एमएस एसक्यूएल सर्वर में मूल्य जोड़े को लागू करने के लिए एक एक्सएमएल डेटा प्रकार का समर्थन है।

उच्च स्तर पर आप एक्सएमएल में उपकरण का मेटा मॉडल विकसित कर सकते हैं। फिर आप स्कीमा एसक्यूएल क्वेरीज और सीआरयूडी कोड उत्पन्न करने के लिए इस मॉडल का उपयोग कर सकते हैं।

स्रोत

2012-07-21 04:07:45

मुझे लगता है कि आप एक नियमित डेटाबेस सामान्यीकरण का सामना करना पड़ा। आप की तरह टेबल की जरूरत है:

Items -> Id, Name, Model, Brand Id 
Brands -> Id, Name 
Attribute Names -> id, name 
Attribute Mappings -> Id, Names Id, Items Id, Attribute Description

मामले में अगर वहाँ एक से अधिक Attribue, गुण टेबल्स में फिर सूची और उत्पाद के साथ संबद्ध आईडी आदि 3 सामान्यीकृत प्रपत्र के साथ आने की कोशिश करें

Database Normalization

स्रोत

2012-07-21 04:13:34 Andrew

यह एक ईएवी मॉडल है जिसका मैंने उल्लेख किया है, नहीं? – neurotik

मुझे नहीं लगता कि यह "नियमित" है। – johnny

विकल्प 1, 2, और 3 मार्टिन फाउलर द्वारा उनकी पुस्तकों में से एक और उनकी वेबसाइट पर उल्लिखित हैं।

Single Table Inheritance (option 1)

Concrete Table Inheritance (option 2, sort of)

Class Table inheritance (option 3)

मेरी प्राथमिकता विकल्प 3. है हर एक चीजों की सामान्य योजना में अपनी जगह है।

ईएवी फ्लाई पर नए गुणों को बहुत अच्छी तरह जोड़ना चाहता है। लेकिन जब डेटा को उपयोगी जानकारी में बदलने का समय आता है, तो एक ईएवी डेटाबेस एक दुःस्वप्न हो सकता है।

मेरे पास लंबा जवाब है, जिसे मैं मांग पर पोस्ट करूंगा।

स्रोत

2012-07-21 08:37:25

अच्छा डेटाबेस डिज़ाइन, गुणों की चर संख्या

उत्तर

संबंधित मुद्दे