क्या इस तरह की टेबल स्कीमा का उपयोग करने का कोई लाभ है:

CREATE TABLE review (
    review_id SERIAL PRIMARY KEY,
    account_id INT REFERENCES account(account_id) NOT NULL, 
    product_id INT REFERENCES product(product_id) NOT NULL, 
    rating SMALLINT NOT NULL, 
    comment TEXT,
    UNIQUE (account_id, product_id)
);

या बाधा ही प्राथमिक कुंजी होनी चाहिए, जैसे:

CREATE TABLE review (
    CONSTRAINT review_pkey (account_id, product_id) PRIMARY KEY,
    account_id INT REFERENCES account(account_id) NOT NULL, 
    product_id INT REFERENCES product(product_id) NOT NULL, 
    rating SMALLINT NOT NULL, 
    comment TEXT,
);
0
Matthew Lerner 13 नवम्बर 2019, 00:08
पुराना स्कूल बनाम नया स्कूल।
 – 
jarlh
13 नवम्बर 2019, 00:20
. . . मैं पहली विधि पसंद करता हूं, क्योंकि मुझे एक कॉलम प्राथमिक कुंजी रखना पसंद है। उस ने कहा, प्रत्येक के अपने फायदे और नुकसान हैं, इसलिए यह कहना आसान नहीं है कि कौन सा बेहतर है।
 – 
Gordon Linoff
13 नवम्बर 2019, 00:35
मुझे पहली विधि भी पसंद है, लेकिन मैं सोच रहा था कि क्या इसके बारे में व्यर्थ डिस्क स्थान से अलग कुछ भी हानिकारक है और मेरे पास जो भावना है उससे अलग कुछ भी फायदेमंद है। बस देखना चाहते हैं कि डीबी डिज़ाइन वाले अधिक अनुभवी लोगों से मुझे क्या याद आ रहा है।
 – 
Matthew Lerner
13 नवम्बर 2019, 01:05

2 जवाब

सबसे बढ़िया उत्तर

दूसरा संस्करण स्पष्ट रूप से बेहतर है, क्योंकि इसमें एक कम कॉलम और एक कम इंडेक्स की आवश्यकता होती है, और कोई डाउन साइड नहीं है।

कॉलम स्पष्ट है, इंडेक्स नहीं हैं, क्योंकि आप उन्हें जोड़ना भूल गए हैं: आपको सभी विदेशी कुंजी स्तंभों पर अनुक्रमित करने की आवश्यकता है ताकि संदर्भित तालिकाओं पर हटाना तेज़ हो सके। कृत्रिम प्राथमिक कुंजी के साथ, आपको review_id, account_id और product_id पर अनुक्रमणिका की आवश्यकता होती है, जबकि आप बिना (account_id, product_id) और product_id पर अनुक्रमणिका के साथ कर सकते हैं।

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

2
Laurenz Albe 13 नवम्बर 2019, 01:33
सामान्य तौर पर, मैं इस कथन से आंशिक रूप से सहमत हो सकता हूं। हालांकि, सभी टेबलों पर id primary key का काफी व्यावहारिक पहलू हो सकता है। उदाहरण के लिए, यह ऐप्स में फ़ॉर्म की पीढ़ी को आसानी से स्वचालित करना संभव बनाता है। इसका धर्म से कोई लेना-देना नहीं है।
 – 
klin
13 नवम्बर 2019, 01:48
सच है, यदि आप ऐसे उपकरण चुनते हैं जो आपको सीमित करते हैं, तो आप सीमित रहेंगे।
 – 
Laurenz Albe
13 नवम्बर 2019, 01:53
1
जब आप उपकरण बनाते हैं, तो एक कॉलम अधिशेष से सरलता अधिक महत्वपूर्ण हो सकती है। यह कोई सीमा नहीं है, बल्कि एक व्यावहारिक विकल्प है।
 – 
klin
13 नवम्बर 2019, 01:59
1
क्षमा करें यदि यह विषय से परे लगता है, लेकिन क्या कोई कारण है कि आप केवल (account_id, product_id) और product_id पर अनुक्रमणिका रखेंगे और इसके अलावा account_id नहीं?
 – 
Matthew Lerner
13 नवम्बर 2019, 02:36
2
@MatthewLerner: उस अनुक्रमण रणनीति का एक बहुत अच्छा कारण है। देखें: dba.stackexchange.com/q/27481/3684
 – 
Erwin Brandstetter
13 नवम्बर 2019, 03:15

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

यदि आप उस तालिका को अन्य तालिकाओं से विदेशी कुंजियों के साथ संदर्भित करने जा रहे हैं:

  • संदर्भ तालिका(ओं) को केवल एकल सरोगेट पीके कॉलम को एफके संदर्भ के रूप में शामिल करने की आवश्यकता है, जो छोटा, तेज और सरल है। यदि संदर्भ तालिका (तालिकाओं) में कई पंक्तियाँ हैं और review नहीं हैं, तो एक एकल उदाहरण पहले से ही अतिरिक्त लागत से review अधिक हो सकता है। वरना, कई उदाहरण हो सकते हैं।
    अनेक पंक्तियों में संदर्भित छोटी लुकअप तालिकाओं के लिए, smallserial सरोगेट PK पर भी विचार करें - यदि वह वास्तव में मदद करता है। देखो:

  • आम तौर पर, संदर्भित तालिकाओं के एफके कॉलम पर भी एक अनुक्रमणिका होगी। दो integer के साथ आपका उदाहरण बहुस्तंभ PK / FK के लिए सबसे अनुकूल है क्योंकि यह अनुक्रमणिका का आकार न्यूनतम रखता है। दो integer कॉलम पर एक बी-ट्री इंडेक्स एक integer पर एक से बड़ा नहीं है (8 बाइट्स आमतौर पर इंडेक्स टुपल्स के लिए न्यूनतम "पेलोड" होता है)। अन्य, बड़े डेटा प्रकार अतिरिक्त अंतर लाएंगे।

  • अगर review को किसी एक कॉलम (account_id, product_id) में कई अपडेट मिलते हैं, तो वे उन दो कॉलम के आधार पर सभी रेफ़रेंसिंग टेबल पर कैस्केड हो जाएंगे। लिखने की लागत को गुणा करता है, कई टेबल और इंडेक्स को ब्लॉट करता है। यदि यह विस्तृत पंक्तियों या कई संदर्भ पंक्तियों में कैस्केड करता है, तो लागतें काफी बढ़ सकती हैं। यह सब हो सकता है एक सरोगेट पीके से बचा जा सकता है - यदि संबंधपरक डिजाइन वास्तव में उस तरह से काम करने वाला है।

यदि review जॉइन के साथ कई प्रश्नों में शामिल है, तो केवल एक के बजाय दो कॉलम में जुड़ना लिखना अधिक कठिन है और थोड़ा अधिक महंगा है। फिर, बड़े डेटा प्रकारों के लिए और भी बहुत कुछ।

उस ने कहा, यदि आपके पास उपरोक्त (या समान) में से कोई भी नहीं है, तो लॉरेन्ज़ के उत्तर को देखें।

वास्तविक लागतों को तौलें, धार्मिक विश्वासों को नहीं।

1
Erwin Brandstetter 13 नवम्बर 2019, 04:07
ठीक है, मुझे धर्म छोड़ देना चाहिए था। मैं खरीदता हूं कि यदि आप यौगिक प्राथमिक कुंजी को संदर्भित करते हैं तो आपको दो कॉलम कुछ जगह बर्बाद कर देते हैं, लेकिन मैं नहीं देख सकता कि यह प्रसंस्करण को धीमा कैसे करेगा। क्या आप व्याख्या कर सकते हैं? साथ ही, मुझे नहीं लगता कि मैपिंग टेबल को संदर्भित करने वाली विदेशी कुंजी बहुत आम हैं। यदि आप प्राथमिक कुंजी अपडेट करते हैं, तो आप कुछ बहुत गलत कर रहे हैं, इसलिए मैं उस तर्क को नहीं खरीदता। मेरी मुख्य चिंता अतिरिक्त कॉलम नहीं है, बल्कि अतिरिक्त अनुक्रमणिका है।
 – 
Laurenz Albe
13 नवम्बर 2019, 10:12
"मैपिंग टेबल" होना जरूरी नहीं है और यह दावा नहीं करना बहुत आम है। If you update primary keys, you are doing something terribly wrong. अधिकतर ऐसा। तो उस स्थिति में दो कॉलम PK बनें न बनाएं। क्या यह मेरी बात नहीं है? अतिरिक्त अनुक्रमणिका है एक चिंता का विषय है, इसके बारे में कोई तर्क नहीं है।
 – 
Erwin Brandstetter
13 नवम्बर 2019, 17:39
मैं सहमत हूं। मैंने किसी एक आईडी को अपडेट करने के बारे में आपके द्वारा कही गई बातों को गलत समझा: मैंने सोचा कि आपका मतलब एक अपडेट है जो संदर्भित तालिकाओं में से एक में प्राथमिक कुंजी परिवर्तन से कैस्केड करता है, लेकिन ऐसा होने की आवश्यकता नहीं है - यह हो सकता है (अभी भी यह मान रहा है कि यह एक है मैपिंग टेबल) कोई व्यक्ति किसी वस्तु से जुड़ी वस्तु को बदलने के लिए मैपिंग को अपडेट करता है। शायद यह भी बार-बार होने वाली घटना नहीं है।
 – 
Laurenz Albe
13 नवम्बर 2019, 19:16