यह एक DB स्कीमा की संरचना करने के लिए एक हास्यास्पद तरीका है, या मैं पूरी तरह से कुछ याद कर रहा हूँ?

Question

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

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

उपयोगकर्ता तालिका:

UserID (primary Key, indexed, no dupes)
FirstName
LastName
Department

अनुरोध तालिका

RequestID (primary Key, indexed, no dupes)
<...> various data fields containing request details
UserID -- foreign key associated with User table

सरल, सही?

सलाहकार ने इसे इस तरह डिजाइन किया (नमूना डेटा के साथ):

UsersTable

UserID  FirstName   LastName
234     John        Doe
516     Jane        Doe
123     Foo         Bar

DepartmentsTable

DepartmentID   Name
1              Sales
2              HR
3              IT

UserDepartmentTable

UserDepartmentID   UserID   Department
1                  234      2
2                  516      2
3                  123      1

RequestTable

RequestID   UserID   <...>
1           516      blah
2           516      blah
3           234      blah

पूरे डेटाबेस को इस तरह से बनाया गया है, जिसमें डेटा का हर टुकड़ा अपनी खुद की तालिका में एनकैप्सुलेटेड है, जिसमें संख्यात्मक आईडी सब कुछ एक साथ जोड़ते हैं। जाहिर तौर पर सलाहकार ने OLAP के बारे में पढ़ा था और 'पूर्णांक के लुकअप की गति' चाहता था।

उसके पास इन सभी तालिकाओं के संदर्भ को पार करने के लिए बड़ी संख्या में संग्रहीत प्रक्रियाएं भी हैं।

क्या यह एक छोटे से मध्यम आकार के SQL DB के लिए मान्य डिज़ाइन है?

टिप्पणी / उत्तर के लिए धन्यवाद ...

Comments

अरे लड़का, अगर यह आपको डब्ल्यूटीएफ कहता है, तो आपने शायद 200+ कॉलम के साथ तालिकाओं को नहीं देखा है और 1000 से अधिक लाइनों को संग्रहीत प्रक्रियाओं को लंबा किया है।

— जॉब

शर्मिंदा महसूस करने के बाद नहीं हटाने के लिए +1। इसे छोड़ने के लिए धन्यवाद, ताकि दूसरे सीख सकें।

— वेन कोर्ट्स

@Job - वास्तव में, मैंने ऐसा नहीं किया है - मैं व्यापार से डीबीए नहीं हूं (अब तक स्पष्ट है! लोल), इसलिए मेरा एसक्यूएल डब्ल्यूटीएफ थ्रेशोल्ड काफी कम है। हालांकि, सलाहकार के डिजाइन के बारे में मेरी पूरी तरह से याद आ रही है मेरे पास अपनी क्षमताओं के लिए डब्ल्यूटीएफिंग है। कभी ऐसा दिन आता है जहां आपको सिर्फ गूंगा लगता है ?

— जिम

@ जय: बधाई हो, आपने एक गूंगे दिन को एक प्रबुद्ध दिन में बदल दिया है ।

— वेन कोर्ट्स

उन अत्यधिक भुगतान सलाहकारों को शाप!

— davidsleeps

Answer 1

मेरे लिए बिल्कुल ठीक है। यह बहुत ही सामान्यीकृत है, जो बहुत अधिक लचीलापन प्रदान करता है जो आपके पास अन्यथा नहीं होगा। डी-सामान्यीकृत डेटा बट में दर्द है।

Comments

आपका जवाब सही समझ में आता है, और मेरे सवाल और स्कीमा को देखते हुए शायद यह सिर्फ तालियों की संख्या है जो वह मुझे भ्रमित कर रहा है। मैंने अपने प्रश्न के लिए उदाहरण को बहुत सरल कर दिया, लेकिन मैं देख रहा हूं कि अवधारणा कैसे ध्वनि है - वह जितना मैं कर सकता हूं उससे कहीं अधिक चीजों को विभाजित कर रहा हूं। आह, मुझे लगता है कि यह एक अच्छी बात है मैं एक डीबीए नहीं हूँ! :)

— जिम

दस मिनट के नियम से डिजाइन करना सीखें: "अब जो सच है वह शायद दस मिनट में नहीं होगा।" सुनिश्चित करें कि आपके डिजाइन परिवर्तन से निपट सकते हैं।

— ब्लरफ्ल

इस स्कीमा का वास्तव में यह फायदा है कि जब कोई कर्मचारी डाला जाता है, तो उनके विभाग का अस्तित्व होता है।

— साइमन रिक्टर

@SimonRichter: यह सच नहीं है। कर्मचारी को मौजूदा विभाग के बिना भी बनाया जा सकता है, और रिवर्स भी।

— डैनियल डिनैनीज़ जूल

@SimonRichter इस डिज़ाइन का लाभ यह है कि, सबसे पहले, विभाग एक अलग इकाई है, और दूसरी बात, कि विभाग और कर्मचारी के बीच कई-से-कई संबंध हैं, जैसे कि ओपी उदाहरण के विपरीत, जहां यह कई था- टू-वन-ईश "(कई-से-एक नहीं कह सकता था, क्योंकि कोई अलग विभाग इकाई यह एक संबंध कहलाने के लिए संदर्भित नहीं थी)।

— डैनियल डेनीज़ जूल

Answer 2

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

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

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

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

EDIT - व्यापार संबंधों के नियम स्पष्ट होने पर, कई संबंधों में से कई का समर्थन किया जाना चाहिए। यदि आपके पास कोई विचार नहीं है कि कई विभागों में एक उपयोगकर्ता कैसे काम करेगा, तो तालिका को जोड़ने में बहुत अधिक बिंदु नहीं है, क्योंकि आपका कोड संभवतः उन मामलों को सही ढंग से नहीं संभाल सकता है जहां उपयोगकर्ता कई विभागों में है।

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

LATER EDIT - एक अन्य कारण यह हो सकता है कि सलाहकार उन सभी मध्यस्थ तालिकाओं को जोड़ना चाहता है जो इस अनुवर्ती प्रश्न में संबोधित की गई हैं , जिसके उत्तर कुछ कारण देते हैं कि डेटाबेस को फिर से तैयार करना आमतौर पर रिफैक्टरिंग कोड की तुलना में कठिन क्यों होता है, जो आपको अपनी ओर खींचता है। "सभी तालिकाओं में आपको कभी भी आवश्यकता पड़ सकती है" दृष्टिकोण।

Comments

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

— जिम

जैसा कि आप बहुत सारी टिप्पणियों से देख सकते हैं, "एक ही बार प्रति X केवल एक टिप्पणी होगी" के बारे में एक स्वस्थ संदेह है। परामर्शदाता खुद को "कैसे आया वहां केवल एक एक्स प्रति वाई" शिकायत हो सकती है। जिनमें से कुछ शायद सामने आएंगे। लेकिन वह ऐसे कोड को बनाए रखने के लिए ज़िम्मेदार नहीं होगा, जिसमें कई जोड़ होते हैं (बहुत बुरा नहीं है, लेकिन कठिन है) और उसे व्यापार नियमों के खिलाफ सही होना होगा जो अभी तक मौजूद नहीं हैं (बुरा) - प्रश्न की कल्पना करें "उपयोगकर्ता सभी को क्यों मिलते हैं प्रत्येक विभाग से अनुमतियाँ, उन्हें प्रत्येक अनुमति का कम से कम प्राप्त होना चाहिए "या कुछ ऐसा।

— पीएस

@ मुझे लगता है कि एक टाइपो है: "क्वेरीज़ नहीं होनी चाहिए जो यह मानती है कि प्रति विभाग केवल एक उपयोगकर्ता है" "प्रश्न यह मान लें कि उपयोगकर्ता केवल एक प्रस्थान में है"?

— BiAiB

@BiAiB - आप सही हैं, यही मेरा कहना था।

— psr

Answer 3

यदि आवश्यकता प्रति उपयोगकर्ता कई विभागों की है, तो यह डिज़ाइन समझ में आता है। इसके बारे में ही शिकायत है UserDepartmentTableएक किराए कुंजी होने UserDepartmentIDकि जरूरत नहीं है (बस बनाने UserIdऔर DepartmentIdएक समग्र प्राथमिक कुंजी)।

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

Comments

... जब तक प्रति उपयोगकर्ता एक से अधिक विभाग संभव नहीं है।

— ब्लरएफल

बिल्कुल, @ बेलप्रफ़। आज का कभी नहीं होने वाला, कल का सीईओ-ए-इज़-ए-एयिरिस्म है, क्योंकि-ए-इट-टू-डू-इट।

— एडम क्रॉसलैंड

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

— ब्लरएफल

YAGNI - डेटाबेस को फिर से बनाया जा सकता है।

— जेफ़ो सिप

@Oded, कुछ ORM मैपर जैसे कि Entity फ्रेमवर्क उन तालिकाओं के साथ अच्छी तरह से काम नहीं करता है, जिनकी समग्र प्राथमिक कुंजी है।

— maple_shaft

Answer 4

आपके प्रश्न में कुछ आवश्यकताएँ स्पष्ट नहीं हैं। सही उत्तर इस बात पर निर्भर करता है कि आपका ग्राहक क्या चाहता है - यदि मैं आप होता, तो मैं ग्राहक से इस बारे में पूछता:

0-उपयोगकर्ता और कर्मचारी के बीच क्या अंतर है?

1-कर्मचारी = उपयोगकर्ता की मानें, तो क्या होगा यदि एक कर्मचारी विभागों को बदलता है?

2-क्या कर्मचारियों का समूह 1 अनुरोध कर सकता है?

3-क्या एक कर्मचारी एक से अधिक विभागों से संबंधित हो सकता है? सीईओ का क्या?

4-क्या कर्मचारियों का एक सबसेट है जिसे अनुरोध करने की अनुमति है?

5-जब कर्मचारी रिकॉर्ड हटा दिया जाता है तो क्या होता है?

6-क्या आप एक अनुरोध हटा सकते हैं? अनुरोध समाप्त होने पर क्या होता है (सुनिश्चित करें कि आप RI द्वारा कर्मचारी रिकॉर्ड को नहीं हटाते हैं)

7-क्या कर्मचारी एक ही बार में "समान" अनुरोध कर सकता है ("वही" परिभाषित करें)

8-कंपनी छोड़ने पर कर्मचारियों के अनुरोधों को कैसे संभालें (उनके अनुरोधों को रद्द करें या अनुरोधों को हटा दें?)

अधिक प्रश्न हो सकते हैं, लेकिन मेरा कहना है कि समाधान सटीक आवश्यकताओं और परियोजना के दायरे पर निर्भर करता है । एक बार जब यह निर्धारित किया जाता है कि स्कीमा सीधे प्राप्त किया जा सकता है। तदनुसार प्रस्तुत दोनों समाधान सही हो सकते हैं।

Comments

+1 ये महान प्रश्न हैं जिन्हें इस प्रकार के स्कीमा को डिजाइन करने से पहले स्पष्ट किया जाना आवश्यक है। मुझे आपके तर्क का प्रवाह पसंद है।

@ Surfer513: मैं आपकी अच्छी टिप्पणी की सराहना करता हूं।

— नोकझोंक

Answer 5

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

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

कहा जा रहा है कि, आपके अत्यधिक भुगतान किए जाने वाले सलाहकार ने ऐसा नहीं करने के कई कारण बताए हैं।

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

Comments

अच्छा विश्लेषण - हालांकि, मैं यह नहीं कहूंगा कि मेरा दिन के काम में एक देवता के रूप में कोई कद है, सिवाय इसके कि मैं यहां केवल वही हूं जो db / c # / vb / etc के बारे में कुछ भी जानता है ... इसलिए लगता है कि मैं हिस्सा हूं डिफ़ॉल्ट रूप से समय देव। यह एक काफी छोटी परियोजना है, इसलिए सलाहकारों ने तालिकाओं और संख्याओं की संख्या को "wtf" कहकर छोड़ दिया, लेकिन (ठीक-ठाक लोक के लिए धन्यवाद मैं अब "oic ..." कह रहा हूं)

— जिम

एक पुराना विषय है, लेकिन अभी भी प्रासंगिक है ... रिफैक्टरिंग बहुत कठिन हो सकता है, कल्पना करें कि आपको एक के बजाय भविष्य में कई विभागों की आवश्यकता होगी, लेकिन उपयोगकर्ताओं में केवल FK के रूप में एक विभाग आईडी है। आप संभवतः डुप्लिकेट रेफ़रेंस (Users.DeptID और UsersDepartmentsTable) या कम्प्लीट कचरा, जैसे कि Users.DeptID, या XML में अल्पविराम से अलग सूचियों के साथ समाप्त करेंगे। सही समाधान को आसानी से जोड़ा नहीं जा सका के रूप में YAGNI या KISS ने सुझाव दिया है, लेकिन बाधित किया जाएगा।

— एरिक हार्ट

Answer 6

आवश्यक जानकारी की पूरी संरचना के बिना मैं नहीं कह सकता कि यह भयानक है या नहीं। लेकिन कम से कम दिखाया गया टुकड़ा "डब्ल्यूटीएफ" डिजाइनों का नहीं है। यह सिर्फ डेटा-संरचना के 3-आरडी सामान्य रूप के रूप में लगता है (ठीक है, हमारे पास सैद्धांतिक रूप से 4-आरडी और 5-वें भी हैं)

कुछ बातचीत में दिखाए गए टुकड़े में "प्राकृतिक" और "कृत्रिम" कुंजियों के दो स्कूलों के बीच UserDepboxTable के लिए जगह हो सकती है। और कुछ नहीं, जैसा कि मैं देख सकता हूं

सामान्यकरण बहुत सारे कारणों से अच्छे DB- डेवलपर / डिजाइनर का नियम है, * de * सामान्यीकरण का उपयोग कभी-कभी विकास के बीच में गति-जीत के लिए किया जाता है।