एसक्यूएल: क्या आपको कई-कई तालिकाओं के लिए एक ऑटो-वृद्धिशील प्राथमिक कुंजी की आवश्यकता है?

Question

कहें कि आपके पास कलाकार और प्रशंसकों के बीच कई-बहुत सारी तालिकाएं हैं। यह तालिका को डिजाइन करने की बात आती है, आप इस तरह की तरह तालिका डिजाइन करते हैं:

ArtistFans 
    ArtistFanID (PK) 
    ArtistID (FK) 
    UserID (FK) 

(ArtistID and UserID will then be contrained with a Unique Constraint 
    to prevent duplicate data) 

या आप दो प्रासंगिक क्षेत्रों के लिए एक यौगिक पी का उपयोग निर्माण करते हैं:

ArtistFans 
    ArtistID (PK) 
    UserID (PK) 

(The need for the separate unique constraint is removed because of the 
compound PK) 

---

देखते हैं कर रहे हैं पूर्व स्कीमा का उपयोग करने के लिए कोई फायदे (शायद अनुक्रमण?)?

Answer 1

ArtistFans 
    ArtistID (PK) 
    UserID (PK) 

ऑटो वृद्धिशील पीके के उपयोग के यहां कोई लाभ नहीं है, भले ही अभिभावक तालिकाओं के पास हों।

मैं भी (UserID, ArtistID) पर स्वचालित रूप से "रिवर्स पीके" इंडेक्स भी बनाउंगा: आपको इसकी आवश्यकता होगी क्योंकि आप दोनों कॉलम द्वारा तालिका से पूछेंगे।

ऑटोनंबर/आईडी कॉलम में उनकी जगह है। भौतिक प्लेटफार्म के आधार पर सामान्यीकरण प्रक्रिया के बाद आप कुछ चीजों को बेहतर बनाने के लिए चुनते हैं। लेकिन लिंक तालिकाओं के लिए नहीं: यदि आपका braindead ORM जोर देते हैं, तो ORMs बदल ...

संपादित करें, अक्टूबर 2012

यह ध्यान रखें कि आप अभी भी अद्वितीय (UserID, ArtistID) और (ArtistID, UserID) अनुक्रमित आवश्यकता होगी महत्वपूर्ण है। एक ऑटो increments जोड़ना बस अधिक जगह (स्मृति में, केवल डिस्क पर नहीं) का उपयोग नहीं किया जाना चाहिए

Answer 2

मैं आपके द्वारा सूचीबद्ध पहले फॉर्म का उपयोग करने के किसी भी कारण से नहीं सोच सकता। यौगिक प्राथमिक कुंजी ठीक है, और एक अलग, कृत्रिम प्राथमिक कुंजी (विदेशी कुंजियों पर आपको आवश्यक अनूठी बाधा के साथ) को गणना करने और स्थानांतरित करने के लिए बस अधिक समय लगेगा।

Answer 3

समग्र प्राथमिक कुंजी का उपयोग करने का मानक तरीका है। एक अलग ऑटोइनक्रिकमेंट कुंजी में जोड़ना सिर्फ एक विकल्प बनाना है जो आपके पास पहले से मौजूद है। उचित डेटाबेस सामान्यीकरण पैटर्न autoincrement का उपयोग करने पर दिखेगा।

Answer 4

भले ही आप एक पहचान कॉलम बनाते हैं, यह प्राथमिक कुंजी नहीं है।

ArtistFans 
    ArtistFanId 
    ArtistId (PK) 
    UserId (PK) 

पहचान कॉलम अन्य संबंधों के संबंध में इस संबंध को जोड़ने के लिए उपयोगी हो सकते हैं। उदाहरण के लिए, यदि कोई निर्माता तालिका थी जिसने कलाकार-उपयोगकर्ता संबंध बनाने वाले व्यक्ति को निर्दिष्ट किया है, तो यह समग्र ArtistId + UserId प्राथमिक कुंजी के बजाय ArtistFanId पर एक विदेशी कुंजी हो सकती है।

इसके अलावा, पहचान कॉलम की आवश्यकता होती है (या कुछ ओआरएम पैकेजों के संचालन में काफी सुधार होता है)।

Answer 5

अजीब बात है कि कैसे सभी उत्तर संस्करण 2 पक्ष, इसलिए मैं असंतोष और संस्करण 1 के लिए बहस करने के लिए है;)

शीर्षक में सवाल का जवाब करने के लिए: नहीं, तुम इसकी आवश्यकता नहीं है। लेकिन ...

में एक ऑटो-वृद्धिशील या पहचान कॉलम होने के बाद प्रत्येक तालिका आपके डेटा मॉडल को सरल बनाती है ताकि आप जान सकें कि आपकी प्रत्येक तालिका में हमेशा एक एकल पीके कॉलम होता है।

परिणामस्वरूप, प्रत्येक तालिका (विदेशी कुंजी) एक तालिका से दूसरे में हमेशा प्रत्येक तालिका के लिए एक कॉलम होता है।

आगे, यदि आप फॉर्म, सूचियों, रिपोर्ट्स, लॉगिंग आदि के लिए कुछ एप्लिकेशन ढांचे लिखना चाहते हैं तो आपको केवल एक पीके कॉलम के साथ तालिकाओं से निपटना होगा, जो आपके ढांचे की जटिलता को सरल बनाता है।

इसके अलावा, डिस्क स्थान के संदर्भ में एक अतिरिक्त आईडी पीके कॉलम आपको बहुत अधिक खर्च नहीं करता है (अरब-रिकॉर्ड-प्लस टेबल को छोड़कर)।

बेशक, मुझे एक नकारात्मक पक्ष का उल्लेख करने की आवश्यकता है: दादा-अभिभावक-बाल संबंध में, बच्चा अपनी दादाजी जानकारी खो देगा और उसे पुनः प्राप्त करने के लिए एक जॉइन की आवश्यकता होगी।

Answer 6

मान लीजिए कि आप पहले से ही सरोगेट कुंजी (आप अच्छी कंपनी में हैं) का भक्त हैं, सभी तरह से जाने के लिए एक मामला बनना है।

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

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

मैं इसे अंगूठे का नियम भी नहीं कहूंगा, कुछ विचार-विमर्श के बारे में। मेरे अनुभव में, कुछ पतले रिश्ते अतिरिक्त डेटा के आसपास ले जाते हैं, अनिवार्य रूप से खुद में संस्था बन जाते हैं, जो सरोगेट कुंजी के योग्य होते हैं।

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

मेरे लिए, एक बार काटकर, दो बार शर्मीला - मैं गेट से सरोगेट कुंजी के लिए जाता हूं।

Answer 7

मेरी राय में, शुद्ध SQL आईडी कॉलम में आवश्यक नहीं है और इसका उपयोग नहीं किया जाना चाहिए। लेकिन ओआरएम ढांचे जैसे कि हाइबरनेट के लिए, कई से अधिक संबंधों का प्रबंधन यौगिक कुंजी आदि के साथ आसान नहीं है, खासकर अगर तालिका में अतिरिक्त कॉलम हैं।

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

तब मैं अपनी परियोजना में किसी अन्य तालिका की तरह तालिका का इलाज करता हूं।