बड़ी संख्या में कॉलम के लिए डेटाबेस स्कीमा डिज़ाइन

Question

मेरे पास एक उपयोग केस है जहां मुझे संदर्भ डेटा मॉडल करने की आवश्यकता है। आइस क्रीम के विभिन्न स्वाद। मान लें कि मेरे पास आइस क्रीम के 50 स्वाद हैं: -

• 20 विशेषताएँ उदा। फ्रीजिंग-टेम्प, क्रीमनेस सभी स्वादों में साझा किया जाएगा
• आइसक्रीम के प्रत्येक स्वाद में 20-30 विशेषताएं होंगी जिन्हें अन्य स्वादों के साथ साझा नहीं किया जाएगा। : -
  • स्ट्राबेरी आइसक्रीम खट्टापन, फल ​​प्रतिशत आदि ट्रैक कर सकते हैं
  • चॉकलेट आइसक्रीम कड़वाहट, कोको स्तर आदि

कैसे मैं इस डेटा बड़े करीने से मॉडल हैं एक डेटाबेस में ट्रैक कर सकते हैं आदर्श, भंडारण/पुनर्प्राप्ति बिंदु से पूरी तरह से मॉडल?

विकल्प के बारे में सोच सकते हैं: - स्वाद प्रति

1. एक मेज। इसके लिए 50 टेबल की आवश्यकता होगी, और प्रत्येक तालिका में 20 कॉलम होंगे जो एक दूसरे के साथ ओवरलैप होंगे, और 20-30 विशेषताओं जो स्वाद के लिए अद्वितीय होंगे।
   • सकारात्मक: मॉडल प्रत्येक स्वाद के डेटा काफी अच्छा
   • विपक्ष: स्तंभ ओवरलैप और टेबल की बड़ी संख्या सभी जायके के लिए
2. एक मेज की जरूरत है। इसे केवल 1 टेबल की आवश्यकता होगी, लेकिन 1000+ कॉलम की आवश्यकता होगी जिनमें से अधिकांश खाली होंगे।
   • सकारात्मक: मॉडल सामान्य रूप में आइसक्रीम के डेटा, काफी अच्छी तरह से
   • विपक्ष: स्तंभों की बड़ी संख्या और सभी जायके के लिए
3. एक कुंजी-मान तालिका 'बर्बाद' अंतरिक्ष की बड़ी राशि, साथ स्वाद आईडी, विशेषता नाम और विशेषता मान।
   • पेशेवरों: सबसे सरल बनाने के लिए और डेटा सम्मिलित
   • विपक्ष: कठिन, निकालने के लिए नहीं वास्तव में एक डेटा मॉडल से प्रति, मुश्किल विशेषताओं के लिए की कमी के रूप में, या अन्य विशेषताओं

से संबंधित विशेषताओं के लिए

Answer 1

मेरे पास सभी सामान्य विशेषताओं के साथ एक तालिका होगी, फिर गैर-साझा विशेषताओं के लिए दूसरा। उदाहरण के लिए:

CREATE TABLE ICE_CREAM_FLAVOR 
    (FLAVOR   VARCHAR2(100) PRIMARY KEY, 
    FREEZING_TEMP NUMBER, 
    CREAMINESS  NUMBER, 
    ETC    VARCHAR2(25), 
    BLAH   NUMBER); 

CREATE TABLE ICE_CREAM_FLAVOR_ATTRIBUTE 
    (ID_ICF_ATTRIBUTE NUMBER, -- should be populated by an insert trigger 
    FLAVOR   VARCHAR2(100) 
    NOT NULL 
    REFERENCES ICE_CREAM_FLAVOR(FLAVOR), 
    ATTRIBUTE_NAME VARCHAR2(25), 
    ATTRIBUTE_VALUE VARCHAR2(100)); 

आपका माइलेज भिन्न हो सकता है।

साझा करें और आनंद लें।

Answer 2

मैं सुझाव देना चाहता हूं, आप 3 अलग-अलग टेबल बना सकते हैं।

1. आइसक्रीम स्वाद: आप आइसक्रीम के सभी जायके स्टोर कर सकते हैं। यह icecream_flavor_master तालिका होगी। मान लें कि क्या आपके पास 50 पंक्तियों की तुलना में 50 स्वाद होंगे, जैसे स्ट्रॉबेरी, चॉकलेट इत्यादि।

2. आइसक्रीम विशेषताएँ: आप आइसक्रीम के सभी गुणों को स्टोर कर सकते हैं। यह icecream_attribute_master तालिका होगी। चलो का कहना है कि यदि आप 50 पंक्तियों की तुलना में 50 विशेषताएं बना होगा, खट्टापन, कड़वाहट, फल प्रतिशत, कोको स्तर आदि जैसे

3. आइसक्रीम स्वाद गुण: आप इस तालिका में icecream_flavor_master और icecream_attribute_master की प्राथमिक कुंजी स्टोर कर सकते हैं, बनाने के लिए स्वाद और आइसक्रीम की विशेषता के बीच संबंध।

मुझे और जानकारी के लिए बताएं।

Answer 3

कभी भी गलत प्रकार में कोई मान संग्रहीत न करें।

जो भी डिजाइन आप चुनते हैं, यह सुनिश्चित करें कि मानों उनके प्राकृतिक प्रारूप में जमा हो जाती हैं। NUMBER, DATE, VARCHAR2, CLOB, XMLTYPE, CLOB (IS JSON), TIMESTAMP, आदि का उपयोग करें। स्ट्रिंग में सब कुछ क्रैक करने का प्रयास करने से कई समस्याएं उत्पन्न हो जाएंगी। आप सत्यापन, सुविधा, प्रदर्शन, और प्रकार की सुरक्षा खो देते हैं।

उदाहरण के लिए, यहां एक सामान्य प्रकार की सुरक्षा समस्या है। 25% से अधिक फल वाली आइसक्रीम खोजने के लिए इस सरल क्वेरी की कल्पना करें:

select * 
from ice_cream_flavor_attribute 
where attribute_name = 'Fruit Percentage' 
    and attribute_value > 25; 

क्या आप बग देखते हैं? क्या आप देखते हैं कि एक ही डेटा के साथ एक ही प्रश्न, एक दिन काम कर सकता है और अगले ORA-01722: invalid number के साथ विफल हो सकता है?

एक प्रश्न लिखना मुश्किल है जो ओरेकल को एक विशिष्ट क्रम में स्थितियों का मूल्यांकन करने के लिए मजबूर करता है। भविष्यवाणियों को पुन: क्रम में मदद नहीं करेगा (99.9% समय)। एक इनलाइन व्यू जोड़ने से मदद नहीं मिलेगी (99.9% समय)। CASE कथन का उपयोग करना काम करेगा लेकिन 100% समय नहीं होगा। संकेतों का उपयोग करना काम करेगा लेकिन मुश्किल है। एक इनलाइन व्यू का उपयोग करना और ROWNUM समस्या को हल करने का मेरा पसंदीदा तरीका है लेकिन यह अजीब लगता है और समझना मुश्किल है।

---

आप एक इकाई गुण मान मॉडल उपयोग करना आवश्यक है (और यदि आप 1000 से अधिक विशेषताओं का यह अपरिहार्य हो सकता है), कम से कम सही प्रकार का उपयोग करें।

अंतरिक्ष के बारे में चिंता न करें - एक शून्य कॉलम अधिकांश 1 बाइट पर उपयोग करता है।

शिकायतों के बारे में चिंता न करें "लेकिन फिर हमारे प्रश्न अधिक जटिल हैं, हमें हमेशा यह जानने की आवश्यकता है कि कौन से कॉलम का उपयोग करना है!" - वास्तव में लगभग कुछ भी उपयोगी नहीं है जो आप इसके प्रकार को जानने के बिना मूल्य के साथ कर सकते हैं। हर बार जब आप एक मूल्य पढ़ते हैं या लिखते हैं तो आपको पहले से ही इस प्रकार के बारे में सोचना होगा।

Answer 4

आप स्वादों के वर्गों में स्वादों को समूहित करने में सक्षम हो सकते हैं, जो कुछ विशेषताओं को साझा करते हैं। यह खुद को कक्षाओं और उप-वर्गों में उधार देता है जो अन्य वर्गों का विस्तार करते हैं।

यदि आप इस पर ईआर मॉडलिंग करना चाहते हैं, तो वेब पर "सामान्यीकरण/विशेषज्ञता" देखें। कुछ वेबसाइटें इसे "विस्तारित ईआर मॉडलिंग" या ईईआर की सुविधा कहेंगी।

यदि आप ईआर डिज़ाइन को लागू करने के लिए संबंधपरक तालिकाओं को डिज़ाइन करना चाहते हैं, तो दो पैटर्न देखें: एकल तालिका विरासत और कक्षा तालिका विरासत।
https://stackoverflow.com/tags/single-table-inheritance/info

https://stackoverflow.com/tags/class-table-inheritance/info

इसके अलावा, वेब पर इस विषय पर मार्टिन फाउलर की उपचार पर गौर, या अपने पाठ्यपुस्तकों में से एक में।

Answer 5

ईसीएम (एंटरप्राइज़ सामग्री प्रबंधन) में विशाल डेटा के लिए कौन से बड़े विक्रेता काम कर रहे हैं, जहां आपके पास एक समान परिदृश्य है (कस्टम विशेषताओं वाले कई कस्टम क्लासेस, उनमें से कुछ समान हो सकते हैं, विशेषताओं पर विभिन्न प्रकार हैं):

3. स्वाद आईडी, विशेषता नाम और विशेषता मान के साथ सभी स्वादों के लिए एक महत्वपूर्ण मूल्य तालिका।

वे प्रति प्रकार एक कुंजी-मूल्य तालिका (स्ट्रिंग, संख्या, दिनांक इत्यादि) का उपयोग करते हैं।

प्रदर्शन अनुकूलन के लिए, वे इंडेक्स को छोटा रखने और अन्य विशेषताओं के साथ भीड़ को रखने के लिए विशेषताओं के लिए समर्पित तालिकाओं को परिभाषित करने की अनुमति देते हैं।

समर्पित टेबल बनाने के भावना के लिए:

• बड़े पैमाने पर उपयोग (होने कई पंक्तियों)
• बुरा हिस्टोग्राम (झंडे की तरह)

अन्यथा ओरेकल सूचकांक बरगलाया जा सकता है, और पूर्ण तालिका का उपयोग कर सकते है सबसे तेज़ पहुंच, जो वास्तव में खराब होगी। तो बड़ी मात्रा में डेटा होने पर प्रदर्शन के बारे में जल्दी सोचें।