मुझे कई रिश्तों के लिए एक टेबल क्यों नहीं चाहिए?

12

मान लें कि मेरे डेटाबेस में कई संबंध हैं, उदाहरण के लिए स्टोर, कर्मचारी और बिक्री, और मैं एक साधारण द्विआधारी संबंध के साथ जोड़े जोड़ना चाहता हूं। व्यक्तिगत रूप से मैं Employee_Store और Employee_Sale नाम की टेबल बनाऊंगा जिसमें एक प्राकृतिक कुंजी विदेशी कुंजियों से बनी होगी।

अब, मेरा सहयोगी कई रिश्तों के लिए एक तालिका बनाने पर जोर देता है। उपरोक्त उदाहरण के लिए एक तालिका हो सकती है जिसका नाम EmployeeLinks है:

EmployeeLinks(
    IdLink int PK, 
    IdEmployee int FK null,
    IdStore int FK null,
    IdSale int FK null,
    LinkType int not null
)

कृपया मुझे अच्छे कारणों से मदद करें कि यह एक अच्छा विचार क्यों नहीं है। मेरे अपने तर्क हैं लेकिन मैं उन्हें निजी रखना चाहूंगा और आपकी निष्पक्ष राय सुनूंगा।

संपादित करें:

प्रारंभ में ऊपर दी गई तालिका में कोई प्राथमिक कुंजी (!) नहीं होगी। क्योंकि विदेशी कुंजियाँ शून्य करने की अनुमति देती हैं इसलिए सरोगेट कुंजी एकमात्र विकल्प है।

database-design

— टोमाज़ प्लसकिविज़
स्रोत

3

यह ओटीएलटी या ईएवी की तरह है लेकिन इससे भी बदतर है क्योंकि यह पंक्तियों के बजाय स्तंभों को आगे बढ़ाता है !

— onedaywhen

1

संबंधित प्रश्न: क्या इसे एक मेज पर कई अशक्त FKs रखने के लिए एक बुरा अभ्यास माना जाएगा ।

— onedaywhen

13

आपके सहयोगी इस लिंक तालिका के लिए प्राथमिक कुंजी के रूप में क्या प्रस्तावित करते हैं?
प्राथमिक कुंजी कॉलम निश्चित रूप से पूर्ण नहीं हो सकते हैं: ऊपर की तालिका अशक्त है।

ऊपर दिए गए उदाहरण में कोई प्राकृतिक पंक्ति पहचानकर्ता (जो कि एक PK है) नहीं है (एक पहचान स्तंभ प्राथमिक कुंजी नहीं है), इसलिए यह किसी भी मॉडलिंग प्रक्रिया में विफल रहता है । कुछ मॉडल (ERD, ORM, IDEF1X, जो भी हो) के बिना टेबल बनाने के बारे में भी मत सोचो

आपको यह सुनिश्चित करने के लिए CHECK बाधाओं की भी आवश्यकता होगी कि आपके पास 3 तरह के लिंक नहीं हैं।

अंत में, आप 4 वें और 5 वें सामान्य रूप क्षेत्र में भटक रहे हैं, लेकिन गलत कारणों से।

मुझे इंटरनेट पर कोई उदाहरण नहीं मिल रहा है: यह दर्शाता है कि यह कितना बेवकूफ है

— GBN
स्रोत

4

+1 के लिएI can't find any examples on the internet: that shows how stupid this is

— JNK

मैंने इसे प्राथमिक कुंजी के बारे में स्पष्ट किया। इसके अलावा, जाहिरा तौर पर मेरे सहयोगी वास्तव में इस तरह के डिजाइन से पहले आए हैं या इसलिए मुझे बताया गया है

— टोमाज़ प्लसकिविक्ज़

@ टोमसज़ प्लसकीविज़: एक सरोगेट कुंजी प्राथमिक कुंजी नहीं है! इसे कार्यान्वयन के समय प्राकृतिक कुंजी के पूरक के लिए चुना जाता है। देखें dba.stackexchange.com/a/13779/630 इसके अलावा, आपके सहयोगी को हमें एक आधिकारिक लेख दिखाना चाहिए जो इस तकनीक को प्रदर्शित करता है। मैंने अपने समय में कूड़े के ढेर देखे हैं, लेकिन मैं उन्हें नहीं दोहराता ...

— 24'12

12

पहला व्यावहारिक कारण जो मैं सोच सकता हूं वह है प्रदर्शन।

"पारंपरिक" मॉडल में, आपके पास Idemployee, Idstoreया जो भी क्षेत्र हैं, उन पर एक अद्वितीय सूचकांक हो सकता है , और लुकअप पर शानदार प्रदर्शन प्राप्त कर सकते हैं । आवेषण के लिए बनाए रखना भी आसान है। यूनीक इंडेक्स आपको अधिक बार मिलाते हैं, जो बहुत JOINतेजी से धमाका कर सकते हैं ।

आपके उदाहरण के मॉडल में, अच्छा प्रदर्शन पाने के लिए आपको मेज पर हर FK फ़ील्ड पर एक न्यूनतम पर एक एकल फ़ील्ड इंडेक्स की आवश्यकता होगी, आदर्श रूप से संदर्भित किए जाने वाले सभी संयोजनों पर एक कवरिंग इंडेक्स, अर्थात:

कर्मचारी / स्टोर
कर्मचारी / बिक्री

मुझे यकीन नहीं है कि लिंक्टाइप क्या है लेकिन यदि आप इसे संदर्भित करते हैं, तो इसे संभवतः अनुक्रमित किया जाना चाहिए।

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

यह आपके तर्क को भी उलझा देगा। आपको कर्मचारी पर एक खोज करने की आवश्यकता होगी, एक खाली स्टोर मान के साथ एक पंक्ति ढूंढें, और अपडेट करें; या, बस हर नई कड़ी के लिए एक नई पंक्ति डालें, जो खेतों को मजबूत करने के उद्देश्य को हराती है।

मूल रूप से आप MORE डिस्क स्थान का उपयोग कर रहे होंगे, और अधिक कारण के लिए अपने तर्क को बनाए रखने के लिए और अधिक अनुक्रमित कर रहे हैं। केवल "लाभ" यह कम तालिकाओं से निपटने के लिए है।

— JNK
स्रोत

लिंक टाइप कॉलम एक विभेदक का कुछ है। सिर्फ यह बताने से कि कौन सी जोड़ी वास्तव में संबंधित है। यदि आप मुझसे पूछते हैं, तो केवल गर्भनिरोधक के लिए जोड़ता है।

— टॉमसज प्लसकाइक्ज

@TomaszPluskiewicz मुझे लगता है कि उसे दिखाने का सबसे अच्छा तरीका यह है कि वह क्यों चूसता है, इसमें दोनों प्रकार की तालिकाओं के साथ एक नमूना डेटासेट बनाने और कुछ प्रश्न चलाने के लिए है। उनका मॉडल एक पारंपरिक मॉडल की तुलना में बहुत धीमा होगा

— जेएनके

4

यदि उन संबंधों में समान विशेषताएँ और / या यदि आप एक से अधिक रिश्तों पर डेटा एकत्र करना चाहते हैं, तो एक तालिका में कई रिश्तों को रखना उपयोगी हो सकता है।

यदि उपयोगकर्ता द्वारा रनटाइम के दौरान संबंधों के प्रकार को परिभाषित किया गया है, तो यह आवश्यक है। हालाँकि ऐसा बहुत कम ही होता है।

आपके उदाहरण में रिश्ते विशेषताओं को साझा नहीं करते हैं, रिश्ते भी दो अलग-अलग तालिकाओं का उल्लेख करते हैं। इससे बाधाओं को लागू करना मुश्किल हो जाता है और डिजाइन भी कम सहज होता है।

मैं केवल उस डिज़ाइन को चुनता हूं यदि टेबल बनाने से सचमुच पैसे खर्च होते हैं।

— जेएमडी कोलेससे
स्रोत