विभिन्न उत्पाद प्रकारों के लिए अलग-अलग तालिकाओं का निर्माण करना है या नहीं?

25

मैं एक डेटाबेस डिजाइन करने की प्रक्रिया में हूं और मैं अपने शुरुआती डिजाइन निर्णयों के बारे में दूसरे विचार रख रहा हूं ...

उत्पाद प्रकार इस प्रकार हैं ... मॉडल, भाग, प्रतिस्थापन भाग किट और विकल्प।

विकल्प ए (पहला डिज़ाइन): मैंने उपरोक्त उत्पाद प्रकारों के लिए अलग-अलग टेबल रखने की योजना बनाई है। मैं कहता हूं कि प्रत्येक तालिका में लगभग 75% क्षेत्र समान होंगे।

मैंने प्रत्येक उत्पाद प्रकार को अलग-अलग तालिकाओं के रूप में बनाया क्योंकि संघों को उनके बीच बनाने की आवश्यकता है। उदाहरण के लिए, एक मॉडल में कई विकल्प हो सकते हैं और एक विकल्प में कई मॉडल हो सकते हैं। एक विकल्प में भी कई भाग हो सकते हैं और एक भाग में कई विकल्प हो सकते हैं ... और इसी तरह ...

विकल्प बी: अलग-अलग तालिकाओं के बजाय मैं उत्पाद नामक एक तालिका बना सकता हूं जिसमें मॉडल, भाग, प्रतिस्थापन भाग किट और विकल्प शामिल हैं। मेरे पास मॉडल, विकल्प, आदि के बीच अंतर करने के लिए एक क्षेत्र हो सकता है जिसे कहा जाता है, मुझे लगता है कि कुछ उत्पाद प्रकारों के लिए कई फ़ील्ड का उपयोग नहीं किया जाएगा (बाएं नल)। मैं यह अनुमान लगा रहा हूं कि "सर्वश्रेष्ठ प्रथाएं" कहां से चलेंगी?

विकल्प बी डीबी डिजाइन की जटिलता को काफी कम कर देगा। जब मैं प्रश्नों के लिए डेटा निकालता हूं तो मुझे मेजों का एक गुच्छा संदर्भित करने के बारे में चिंता नहीं करनी होगी ...

database-design database-recommendation

— payling
स्रोत

2

इस संकेत पर मेरा सुझाव है कि आप ऐसी स्प्रेडशीट बनाएं जो आपके टेबल लेआउट की नकल करें और उन्हें डेटा से भरें। यह मौजूद किसी भी कमजोरी को उजागर करेगा।

— माइकल रिले - AKA Gunny

यदि आप अलग-अलग तालिकाओं में हैं, तो आप विभिन्न उत्पादों पर विदेशी कुंजियों को कैसे इंगित करेंगे? कृपया तालिका विरासत पर पढ़ें।

— नील मैकगिन

8

यदि यह मेरा डिज़ाइन निर्णय होता, तो मैं शायद 'विकल्प C' (संशोधित विकल्प a) के साथ जाता।

पहला, 'विकल्प बी' क्यों नहीं:

एक बात के लिए, मुझे यह स्पष्टता पसंद है कि प्रत्येक उत्पाद का अपना टेबल अफेयर्स है। यदि यह प्रकार निर्धारित करने के लिए फ़ील्ड के साथ सभी एक बड़ी तालिका है, तो संबंध उतना स्पष्ट नहीं है।

दूसरे के लिए, अनुक्रमण रणनीति को हमेशा उस प्रकार के क्षेत्र को सूचीबद्ध करने की आवश्यकता होगी। चूंकि यह केवल 4 प्रकार का है, इसलिए इंडेक्स कार्डिनैलिटी बेहद कम है ( SELECT * FROM product_table WHERE type='X'मूल रूप से वैसे भी एक पूर्ण टेबल स्कैन कर रहा है)

विकल्प सी

एक पैरेंट टेबल बनाएं, जिसमें सभी प्रकार के शेयर वाले केवल कॉलम हों
प्रत्येक उत्पाद प्रकार बनाएं क्योंकि यह अपने व्यक्तिगत कॉलम के साथ एक अतिरिक्त के साथ है: मूल तालिका के लिए एक लिंक
प्रत्येक 'लिंक' तालिका बनाएं: संबंधित कुंजियों के लिंक के साथ Product_Option, Model_option, आदि।
पारस्परिक लिंक वाले लोगों के लिए (MODEL_OPTION, OPTION_MODEL) आगे जाएं और उन तालिकाओं को भी बनाएं। यह किसी को भी देखने के लिए अपने जुड़ाव में स्पष्टता जोड़ देगा।

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

— डेरेक डाउनी
स्रोत

5

अब केवल 4 प्रकार हैं, लेकिन अगर बाद में और जोड़ दिए जाएं तो क्या होगा? मुझे यकीन है कि अमेज़ॅन की मुख्य उत्पाद तालिका को मूल रूप से "पुस्तकें" कहा जाता था, लेकिन क्या आपको लगता है कि उनके पास अब प्रत्येक उत्पाद प्रकार के लिए एक अलग तालिका है? मुझे नहीं लगता कि प्रत्येक प्रकार की अपनी तालिका होनी चाहिए, लेकिन आप अतिरिक्त गुणों के लिए एक ईएवी मॉडल का उपयोग कर सकते हैं जो प्रत्येक प्रकार के सामान्य रूप में हो सकते हैं।

— हारून बर्ट्रेंड

1

@ एरॉन फेयर पॉइंट भविष्य में उत्पाद प्रकारों की वृद्धि के बारे में बताता है। यदि इस परिदृश्य में 10 + प्रकार के उत्पादों का विस्तार हो सकता है, तो मैं पुनर्विचार करूंगा। लेकिन, मुझे लगता है कि विशिष्ट उत्पाद तालिकाएँ थोड़े उत्पाद प्रकारों के लिए उचित डिज़ाइन विकल्प हैं।

— डेरेक डाउनी

1

विकल्प सी: क्या लिंक टेबल होना आवश्यक है? मुझे लगता है कि Product_Option पीके उत्पाद तालिका के पीके से मेल खाएगा और इससे दोनों तालिकाओं को जोड़ने के लिए संघ का निर्माण होगा।

— पेइंग

उदाहरण के रूप में Product_option का उपयोग करना, स्कीमा (मेरे दिमाग में) होगा: आईडी, productID, विकल्प। productIDएक FK टू होगा product.id, और optionIDFK to है option.id। लिंक टेबल से मेरा मतलब यही है। और हां, इस डिज़ाइन में एक उत्पाद को कई विकल्पों से लिंक करने की अनुमति देना आवश्यक है।

— डेरेक डाउनी

ठीक है मै समझ गया। मैंने आपको जो टाइप किया था, वह गलत है।

— बजे

7

मैं आपको "सही" संबंधपरक मॉडल के साथ शुरू करने का सुझाव दूंगा, आपका विकल्प A. यदि उस मॉडल का विशिष्ट उपयोग आपको कुछ क्षेत्रों में असामान्यता की ओर ले जाता है, तो ऐसा करने से डरो मत।

मैं पिछले हफ्ते एक सहकर्मी के साथ चर्चा कर रहा था कि कैसे स्कीमा डिज़ाइन को अक्सर कुछ ऐसा माना जाता है जो पत्थर में सेट होता है और कभी भी बदल नहीं सकता है। अजीब, यह देखते हुए कि किसी अनुप्रयोग की हर दूसरी परत में स्वीकृत अभ्यास में कैसे रिफैक्टिंग होती है, एक डेटाबेस स्कीमा को फिर से तैयार करना अभी भी अव्यावहारिक के रूप में देखा जाता है।

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

— मार्क स्टोरी-स्मिथ
स्रोत

2

बहुत के समान यह आवाज़ सामग्री / एकाधिक cardinalities के बिल heirarcy कि पॉल Neilsen में वर्णन करता है अध्याय 17 की एसक्यूएल सर्वर 2008 बाइबिल ।

पूरा अध्याय बहुत अच्छा पढ़ा गया है और विशिष्ट खंड जो आपके कई-कई मुद्दों को संबोधित करता है, पृष्ठ 416-419 पर पाया गया है।

यह सबसे अच्छी चर्चा है जो मैंने डेटा डिज़ाइन के विस्फोट भागों के बारे में देखा है ।

— माइकल रिले - उर्फ गनी
स्रोत

यह समाधान विकल्प बी के समान दिखता है (यदि मैं इसे सही ढंग से समझता हूं, जो मुझे यकीन नहीं है कि मैं करूंगा)। मेरे पास मॉडल (विकल्प), किट, आदि के बीच जुड़ाव बनाने के लिए एक मास्टर टेबल (उत्पाद) और एक "लिंक" टेबल (उर्फ बगल की मेज / BillsofMaterials) होगा, क्या यह सही है?

— 18-28 बजे

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

— माइकल रिले - AKA Gunny

भागों में मेरे डिजाइन में "विकल्प" नहीं हैं। मैं विकल्प को कुछ के रूप में परिभाषित करता हूं जो एक मॉडल पर जाता है जो इसे विस्तारित कार्यक्षमता प्रदान करता है। एक विकल्प भागों से बना है। एक मॉडल में कई अलग-अलग विकल्प हो सकते हैं। एक विकल्प कई अलग-अलग मॉडल पर भी फिट हो सकता है।

— पेइंग ऑग

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

— माइकल रिले - AKA Gunny

0

यदि आप एक संभावित परिदृश्य की इमेजिंग कर सकते हैं, जहां लगातार प्रश्न होंगे जो सभी चार उत्पाद प्रकारों में जाते हैं (और मुझे इसकी संभावना है), तो आपका विकल्प बी सबसे अच्छा है।

उत्पाद तालिका में बहुत सारे अप्रयुक्त अशक्त क्षेत्र छोड़ने के बजाय, क्यों न एक ModelProduct तालिका, एक PartProduct तालिका, एक प्रतिस्थापनPartKitProduct तालिका जोड़ें, और उन फ़ील्ड्स में उन प्रकारों के लिए अलग-अलग फ़ील्ड्स को अलग-अलग करें? अपने उत्पाद तालिका के रूप में उन तालिकाओं पर समान प्राथमिक कुंजी का उपयोग करें। जब आप मॉडल्स के साथ काम करना चाहते हैं तो प्रोडक्ट और मॉडलप्रॉडक्ट टेबल से जुड़ें। यह निर्धारित करने की आवश्यकता है कि क्या आपके पास उत्पाद रिकॉर्ड एक हिस्सा है? बस प्रोडक्ट से लेकर पार्टप्रोडक्ट तक लेफ्ट जॉइन करें, और अगर पार्टप्रोडक्ट। [प्राइमरीके] शून्य नहीं है, तो आपके पास एक पार्ट है। यदि यह अशक्त है, तो यह एक हिस्सा नहीं है। वैकल्पिक रूप से, आप उत्पाद तालिका में ProductType फ़ील्ड जोड़ सकते हैं।

— एलन मैकबी
स्रोत

अशक्त क्षेत्र न्यूनतम होंगे, क्योंकि लगभग 75% खेतों का उपयोग हर तालिका में किया जाएगा। मुझे लगता है कि मैं उत्पाद प्रकारों के बीच संबंधों के बारे में अधिक चिंतित हूं। मेरे पास एक ही तालिका की ओर इशारा करते हुए तीन या तो लिंक टेबल होंगे। Model_has_Option दो प्राथमिक कुंजियाँ, उत्पाद तालिका के दोनों उत्पाद आईडी, यदि मुझे उत्पाद प्रकारों का प्रतिनिधित्व करने के लिए केवल एक तालिका का उपयोग करना था। मैं ज्यादा चिंतित हूं कि क्या करना सही है या नहीं।

— payling

जबकि कई कारक हैं जो "सही" निर्णय को प्रभावित करते हैं, विचार करने के लिए दो व्यापक कारक हैं। 1: समग्र प्रदर्शन आवश्यकताओं; 2: अनुकूलनशीलता / जटिलता / स्थिरता। उन दो में से एक शायद दूसरे की तुलना में थोड़ा अधिक महत्वपूर्ण है। यदि आपको गति की आवश्यकता है, तो विकल्प ए पर चिपकाकर इसे असामान्य करें। आपके पास दोहराव होगा; यह अपेक्षित है। यदि आपको नियमित आधार पर स्कीमा के साथ फिडेल करने की आवश्यकता है और गति सबसे महत्वपूर्ण कारक नहीं है, तो विकल्प बी। आप अपनी प्राथमिकताओं को जानकर "सही" हो जाएं, न कि "किसी और की सर्वोत्तम प्रथाओं" का पालन करने से।

— एलन मैक्बी 19