एक डेटाबेस में एक ही प्राथमिक कुंजी अनुक्रम साझा करना?

Question

क्या सभी तालिकाओं में प्राथमिक कुंजी के रूप में एकल अनुक्रम का उपयोग करने के लिए एक स्वीकार्य अभ्यास है (प्राथमिक तालिका के बजाय किसी तालिका के लिए अद्वितीय है, यह सभी तालिकाओं के लिए अद्वितीय है)? यदि हां, तो क्या यह तालिकाओं में एकल प्राथमिक कुंजी अनुक्रम का उपयोग करने से बेहतर है।

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

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

Edit2: टिप्पणियों में एक प्रश्न का उत्तर देने के लिए, यह Oracle 11g के लिए है, लेकिन मैं एक गैर-डेटाबेस विशिष्ट स्तर पर सोच रहा था। यदि यह सवाल डेटाबेस पर निर्भर करता है, तो मुझे यह जानने में दिलचस्पी होगी कि क्यों, लेकिन इस तरह के मामले में मैं ओरेकल के लिए विशिष्ट उत्तर की तलाश में हूं।

Comments

यह आमतौर पर एक भयानक विचार है, प्रदर्शन कारणों से।

— फिल

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

— आरएलएफ

आप कौन से DBMS का उपयोग कर रहे हैं? आकाशवाणी? Postgres? डीबी 2?

— a_horse_with_no_name 16

क्या यह संभव है कि आपने इसका गलत अर्थ निकाला हो? शायद वह वह शाब्दिक नहीं था?

— जेम्सरन

क्या कंपनी डीबीए का वास्तव में मतलब है कि किसी भी तालिका में कोई प्राथमिक कुंजी फ़ील्ड मौजूद नहीं हैं?

— मैक्स वर्नोन

Answer 1

स्वीकार्य है? ज़रूर। सामान्य? लाभकारी नहीं है? संदिग्ध।

मेरी पुरानी नौकरी में हमें एक ऐसी प्रणाली विरासत में मिली थी जहाँ उनका केंद्रीय अनुक्रम जनरेटर था (यह SQL सर्वर सिस्टम बहुत पहले SEQUENCESQL Server 2012 में पेश किया गया था)। यह वास्तव में एक प्रदर्शन अड़चन नहीं था और यह तब तक नहीं होना चाहिए जब तक कि आप प्रति सेकेंड हजारों मान उत्पन्न नहीं कर रहे हों। लेकिन इसने सभी कोड को और अधिक जटिल बना दिया, जो कि बिना किसी अच्छे कारण के था। डिजाइन का आशय यह सुनिश्चित करना था कि यदि सिस्टम में कुछ को 12 का आईडी मान सौंपा गया है, तो सिस्टम में केवल एक चीज आईडी 12 हो सकती है। यह मुझे काफी अटपटा लग रहा था और मैं इसे कभी नहीं समझ पाया। अगर मेरे पास CustomerID = 12 का कोई ग्राहक है, तो मुझे OrderID = 12 के साथ ऑर्डर देने से क्यों रोकता है?

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

Comments

यदि आपको इस तरह के बीच का चयन करना था और केवल प्राथमिक कुंजियों के रूप में यूनीकॉलीफायर्स का उपयोग करना था, तो क्या आपकी प्राथमिकता होगी (हालांकि इसका उत्तर "यह निर्भर करता है") है? ऐसा लगता है कि एक GUID समस्या के चारों ओर उसी तरह काम करेगा, सिवाय इसके कि आपको अपना केंद्रीयकृत प्राथमिक-की-जनरेटर रोल करने के बजाय एक मानक कार्यान्वयन मिलेगा। जाहिर है, एसक्यूएल 2012 में एक सीक्वेंस का उपयोग करने से दोनों चीजें पूरी हो जाएंगी, लेकिन यह मान लेना कि कोई पुराने संस्करण पर है?

— स्क्लरयन

@SqlRyan मुझे यह समझने की आवश्यकता होगी कि एक ऑर्डरआईडी को ग्राहक आईडी से पूरी तरह अलग क्यों होना चाहिए। मैं लगभग निश्चित रूप से इसके लिए एक GUID का उपयोग नहीं करेगा; पहचान की सीमाएँ बेहतर हो सकती हैं (ग्राहक 1 से शुरू होता है, जब आप कोर्स की सीमा को समाप्त करने के करीब आ जाते हैं, तो अलर्ट के साथ ऑर्डर 1 से शुरू होते हैं, 1000000 आदि)।

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

@SqlRyan - खराब प्राथमिक रूप से कार्यान्वित GUID का उपयोग करने के कारण क्लस्टर की गई प्राथमिक कुंजी सभी प्रकार की समस्याओं का कारण बन सकती है। जैसा कि हारून ने कहा, आइडेंटिटी उद्देश्य को बेहतर तरीके से पूरा करती है।

— मैक्स वर्नोन

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

— लॉटनफॉलेग

@AaronBertrand या वैकल्पिक रूप से सरल पूर्णांक पहचानकर्ताओं का उपयोग करें और शुरुआत में कुछ कोड संलग्न करें जब ये ग्राहक का सामना कर रहे हों। जैसे। I1337, C1337 स्पष्ट रूप से एक चालान या ग्राहक

— जेम्सरन

Answer 2

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

हमने GUID के कुछ सूचकांक विखंडन से बचने के लिए क्रमिक GUID को हमारी प्राथमिक कुंजी के रूप में चुना है। अफसोस की बात है कि वे काफी बड़े हैं।

SQL सर्वर नए डिस्क्लेमर () फ़ंक्शन को डिफ़ॉल्ट रूप से लागू करने के माध्यम से अनुक्रमिक GUIDs उत्पन्न कर सकता है, इसलिए बनाए रखने और टोंटी को अवरुद्ध करने के लिए जारी की गई कुंजियों की कोई तालिका नहीं है।

इसने हमें पूरे डेटाबेस में, हमारे पूरे उद्यम में वास्तव में अद्वितीय आईडी दी है क्योंकि वे वास्तव में अद्वितीय हैं।

पाठ्यक्रम की कीमत अंतरिक्ष और इसकी समस्याग्रस्त है जब आपके डेटा को डेटा वेयरहाउस / क्यूब में लाने की कोशिश की जाती है, जहां छोटे इंटीजर कुंजी का उपयोग करने पर गति / आकार की भविष्यवाणी की जाती है।

मुझे यकीन है कि हमने अपने ऐप में कई बग्स को इस्तेमाल करने से बचा लिया है।

Answer 3

मैं कल्पना नहीं कर सकता कि सभी तालिकाओं में एकल अनुक्रम के पीछे क्या कारण हो सकता है। नए मूल्यों को बनाते समय यह सब एक अड़चन पैदा करता है।

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

यहां तक कि सबसे कुशल अनुक्रम जनरेटर के साथ वहाँ हो जाएगा एक काम का बोझ है कि untolerable विवाद का कारण बनता है।

Comments

आप यह जानना चाहते हैं कि अड़चन कैसे पैदा होती है और यह एक बुरा विचार क्यों है।

— मैक्स वर्नोन

Answer 4

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

एक अनुक्रम संख्या का उपयोग प्राथमिक कुंजी के रूप में ही होता है क्योंकि प्रत्येक तालिका में पहचान कॉलम होता है और केवल उस कॉलम का उपयोग प्राथमिककेय में किया जा रहा है। DB भर में एकल अनुक्रम संख्या का कुछ विशिष्ट उपयोग होना चाहिए, लेकिन प्राथमिक दृष्टि से मुझे समझ में नहीं आता है। उदाहरण के लिए मैंने काम किए गए डेटावेयरहाउस प्रोजेक्ट में से एक में, हमारे पास लोडबेंचिड नामक स्तंभ है और ईटीएल से लेकर रिपोर्टिंग तक सभी तालिका के 50% में यह कॉलम है, लेकिन कुछ स्थानों पर इसका अलग अर्थ है। हमने यह सुनिश्चित करने के लिए नंबर जनरेटर के रूप में अनूठे proc का उपयोग किया कि हम संघर्षों को नहीं ढूंढते हैं और हमें मूल फ़ाइल पर वापस पता लगाने में भी मदद करते हैं कि डेटा कहां से आया है और ETL के प्रत्येक विभिन्न चरणों में क्या होता है।

Answer 5

मुझे लगता है कि ऐसा करने का एक कारण यह होगा कि यदि सभी संस्थाएं किसी मूल संस्था से विरासत में मिली हैं। उदाहरण के लिए कहें कि आप किसी भी प्रकार की इकाई पर टिप्पणी करने में सक्षम होना चाहते हैं:

create table god_entity (
  id bigserial primary key
);

create table some_table (
  id bigint primary key references god_entity(id),
  ...
);

create table some_other_table (
  id bigint primary key references god_entity(id),
  ...
);

create table comment (
  id bigint primary key references god_entity(id),
  ...
);

create table entity_comment (
  entity_id bigint not null references god_entity(id),
  comment_id bigint not null references god_entity(id),

  primary key (entity_id, comment_id)
);

आमतौर पर ऐसा नहीं किया जाता है। ।

प्रदर्शन विशेषताओं के बारे में नहीं जानते।