विदेशी कुंजी नामकरण योजना


152

मैं पहली बार विदेशी कुंजी के साथ काम करना शुरू कर रहा हूं और मैं सोच रहा हूं कि क्या उनके लिए उपयोग करने के लिए एक मानक नामकरण योजना है?

इन तालिकाओं को देखते हुए:

task (id, userid, title)
note (id, taskid, userid, note);
user (id, name)

जहां कार्य के पास नोट्स हैं, कार्य उपयोगकर्ता के स्वामित्व वाले हैं, और उपयोगकर्ता लेखक नोट्स हैं।

इस स्थिति में तीन विदेशी कुंजियों का नाम कैसे होगा? या वैकल्पिक रूप से, क्या यह बिल्कुल भी मायने रखता है ?

अपडेट : यह सवाल विदेशी प्रमुख नामों के बारे में है, न कि फील्ड नामों के बारे में!


6
पाठकों के लिए ध्यान दें: नीचे सूचीबद्ध कई सर्वोत्तम प्रथाएँ ओरेकल में अपनी 30 अक्षर नाम की सीमा के कारण काम नहीं करती हैं। एक तालिका नाम या स्तंभ नाम पहले से ही 30 वर्णों के करीब हो सकता है, इसलिए दोनों को एक ही नाम के संयोजन में एक ट्रंकेशन मानक या अन्य चाल की आवश्यकता होती है।
चार्ल्स बर्न

जवाबों:


179

SQL सर्वर में मानक सम्मेलन है:

FK_ForeignKeyTable_PrimaryKeyTable

इसलिए, उदाहरण के लिए, नोट और कार्यों के बीच की कुंजी होगी:

FK_note_task

और कार्यों और उपयोगकर्ताओं के बीच की कुंजी होगी:

FK_task_user

यह आपको 'एक नज़र में' दृश्य देता है कि कौन-सी तालिकाएँ कुंजी में शामिल हैं, इसलिए यह देखना आसान है कि कौन सी तालिकाएँ किसी विशेष (पहले नाम वाली) पर निर्भर करती हैं (दूसरा नाम वाली)। इस परिदृश्य में कुंजी का पूरा सेट होगा:

FK_task_user
FK_note_task
FK_note_user

तो आप देख सकते हैं कि कार्य उपयोगकर्ताओं पर निर्भर करते हैं, और नोट्स दोनों कार्यों और उपयोगकर्ताओं पर निर्भर करते हैं।


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

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

ठीक है ... मेरे पास ओरेकल में प्रत्येक तालिका के लिए अलग-अलग नाम स्थान हैं, इसलिए मुझे आत्म संदर्भ की आवश्यकता नहीं है।
स्टीव मोयर

29
यह सामान्य उपयोग प्रतीत होता है लेकिन जब लोग एक ही टेबल की ओर इशारा करते हुए दो विदेशी चाबियां रखते हैं तो लोग क्या करते हैं। यानी messageटेबल के पास एक है from_user_idऔर वे to_user_idदोनों बन जाएंगे fk_message_userfk_tablename_columnnameइस कारण से (मेरे उदाहरण में fk_message_from_user_id) का उपयोग करना मेरे लिए बेहतर प्रतीत होता है और फिर लक्ष्य तालिका के बारे में अपने कॉलम के नामों को स्पष्ट रखने का प्रयास करें (अर्थात to_user_id स्पष्ट रूप से उपयोगकर्ता तालिका का उल्लेख कर रहा है)
कोड कमांडर

क्या होगा यदि दोनों तालिका में पूर्व के लिए अंडरस्कोर है। user_role और user_addresses? fk_user_addresses_user_role यह भ्रामक नहीं है?
गोविवि एस

38

मैं दो अंडरस्कोर वर्णों को सीमांकक के रूप में उपयोग करता हूं

fk__ForeignKeyTable__PrimaryKeyTable 

ऐसा इसलिए है क्योंकि तालिका के नाम में कभी-कभी अंडरस्कोर वर्ण खुद होंगे। यह आम तौर पर बाधाओं के लिए नामकरण सम्मेलन का अनुसरण करता है क्योंकि डेटा तत्वों के नामों में अक्सर अंडरस्कोर वर्ण शामिल होंगे जैसे

CREATE TABLE NaturalPersons (
   ...
   person_death_date DATETIME, 
   person_death_reason VARCHAR(30) 
      CONSTRAINT person_death_reason__not_zero_length
         CHECK (DATALENGTH(person_death_reason) > 0), 
   CONSTRAINT person_death_date__person_death_reason__interaction
      CHECK ((person_death_date IS NULL AND person_death_reason IS NULL)
              OR (person_death_date IS NOT NULL AND person_death_reason IS NOT NULL))
        ...

3
यह बिल्कुल सबसे अच्छा जवाब है।
फ्रेडरिक क्राउटवल्ड

1
मैंने अभी बहुत विशिष्ट नामकरण सम्मेलन के साथ डर्बी डीबी बनाया है और यह यहां सबसे पठनीय और प्राप्य है। धन्यवाद
एंड्डो

17

कैसे के बारे में FK_TABLENAME_COLUMNNAME?

कश्मीर eep मैं टी एस imple एस tupid जब भी संभव हो।


20
क्योंकि जब आपके पास बहुत सी चाबियाँ और तालिकाओं के साथ एक विशाल db होता है और आपको अपने सॉफ़्टवेयर में स्कीमा अपडेट के दौरान कोई त्रुटि मिलती है, तो यह खोजना बहुत कठिन है कि डेटाबेस की खोज किए बिना विदेशी कुंजी को परिभाषित भी किया जाता है।
JohnC

1
@ जॉन्च अगर एफके कॉलम नामों में कॉलम नाम में अन्य तालिका नाम है, तो क्या यह बताना बहुत आसान नहीं होना चाहिए? यह आपको दो तालिकाएँ और स्तंभ नाम बताता है, जिस पर इसे परिभाषित किया गया है। Ex: FK_Animals_OwnerID-Aimimals और Owners table, OwnerID कॉलम पर परिभाषित
डेविड शेरेट

10

SQL सर्वर से संबंधित Microsoft का एक नोट:

एक पूर्व कुंजी की बाधा को केवल एक अन्य तालिका में एक प्राथमिक कुंजी बाधा से जोड़ा जाना नहीं है; इसे एक अन्य तालिका में एक UNIQUE बाधा के स्तंभों को संदर्भित करने के लिए भी परिभाषित किया जा सकता है।

इसलिए, मैं पारंपरिक प्राथमिक / विदेशी संबंधों की शर्तों के बजाय निर्भरता का वर्णन करने वाले शब्दों का उपयोग करूंगा।

आश्रित (बच्चे) तालिका में समान नाम वाले कॉलम (ओं) द्वारा स्वतंत्र (मूल) तालिका के प्राथमिक कुंजी का उल्लेख करते समय , मैं कॉलम नाम (ओं) को छोड़ देता हूं:

FK_ChildTable_ParentTable

अन्य स्तंभों का संदर्भ देते समय, या स्तंभ के नाम दो तालिकाओं के बीच भिन्न होते हैं, या केवल स्पष्ट होने के लिए:

FK_ChildTable_childColumn_ParentTable_parentColumn

9

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

task (id, userid, title);
note (id, taskid, userid, note);
user (id, name);

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


हेह - यह सटीक शैली है जिसका मैं वास्तव में उपयोग कर रहा हूं (लेकिन कैमलकेस के साथ) - मैंने सोचा कि मैं उनके लिंक को दर्शाने के प्रयोजनों के लिए नामों में थोड़ा अतिरिक्त विवरण जोड़ूंगा।
निकफ

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

5

यह शायद ओवर-किल है, लेकिन यह मेरे लिए काम करता है। जब मैं विशेष रूप से VLDBs के साथ काम कर रहा हूं तो यह मुझे बहुत मदद करता है। मैं निम्नलिखित का उपयोग करता हूं:

CONSTRAINT [FK_ChildTableName_ChildColName_ParentTableName_PrimaryKeyColName]

बेशक अगर किसी कारण से आप एक प्राथमिक कुंजी का संदर्भ नहीं दे रहे हैं, तो आपको इस मामले में एक अद्वितीय बाधा में निहित स्तंभ का संदर्भ देना चाहिए:

CONSTRAINT [FK_ChildTableName_ChildColumnName_ParentTableName_ColumnInUniqueConstaintName]

क्या यह लंबा हो सकता है, हां। क्या इसने रिपोर्ट के लिए जानकारी को स्पष्ट रखने में मदद की है, या मुझे इस बात पर एक त्वरित छलांग लगाई है कि संभावित मुद्दा एक अलर्ट के दौरान है 100% इस नामकरण सम्मेलन में लोगों के विचारों को जानना पसंद करेंगे।


1

मेरा सामान्य दृष्टिकोण है

FK_ColumnNameOfForeignKey_TableNameOfReference_ColumnNameOfReference

या अन्य शब्दों में

FK_ChildColumnName_ParentTableName_ParentColumnName

इस तरह से मैं दो विदेशी कुंजी एक तरह एक ही तालिका को देख कि नाम कर सकते हैं history_info tableके साथ column actionBy and actionToसेusers_info तालिका

यह जैसा होगा

FK_actionBy_usersInfo_name - For actionBy
FK_actionTo_usersInfo_name - For actionTo

ध्यान दें कि:

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

पाठकों के लिए ध्यान दें: नीचे सूचीबद्ध कई सर्वोत्तम प्रथाएँ ओरेकल में अपनी 30 अक्षर नाम की सीमा के कारण काम नहीं करती हैं। एक तालिका नाम या स्तंभ नाम पहले से ही 30 वर्णों के करीब हो सकता है, इसलिए दोनों को एक ही नाम के संयोजन में एक ट्रंकेशन मानक या अन्य चाल की आवश्यकता होती है। - चार्ल्स बर्न्स


यदि आपके पास 3 टेबल डुप्लिकेट FK_Name द्वारा ParentTableName_ParentColumnName एक ही मेज पर FK बिंदु है आपका एक विफल रहा होगा
टोनी दांग

0

यहां जवाब और टिप्पणियों के आधार पर, एक नामकरण सम्मेलन जिसमें एफके टेबल, एफके फ़ील्ड, और पीके टेबल (FK_FKTbl_FKCol_PKTbl) शामिल हैं, को एफके बाधा नाम टकराव से बचना चाहिए।

तो, यहाँ दी गई तालिकाओं के लिए:

fk_task_userid_user
fk_note_userid_user

इसलिए, यदि आप एक ट्रैक जोड़ते हैं जो अंतिम रूप से एक कार्य या एक नोट को संशोधित करता है ...

fk_task_modifiedby_user
fk_note_modifiedby_user

-2

यदि आप अक्सर अपने FK का संदर्भ नहीं दे रहे हैं और MySQL (और InnoDB) का उपयोग कर रहे हैं, तो आप केवल MySQL को आपके लिए FK नाम दे सकते हैं।

बाद के समय में आप कर सकते हैं किसी क्वेरी को चलाकर आप FK नाम पा हैं


4
मैं केवल अपने डाउन-वोट की व्याख्या कर सकता हूं। बस के बारे में हर डेटाबेस प्रणाली बाधाओं का नाम प्रणाली के लिए अनुमति देता है, क्या आप वापस जाने की कल्पना कर सकते हैं और उत्पादन मुद्दे w / 100 टेबल डेटाबेस के दौरान भी जल्दी से पता लगाने की कोशिश कर रहे हैं, यह समझने की कोशिश कर रहा है कि FK__123ee456ff का क्या संबंध है? यह सादा है और बस एक कठिन अभ्यास है। जब आप इस FK पर एक इंडेक्स बनाते हैं तो क्या? सिस्टम के नाम भी? इसलिए जब सूचकांक IX_007e373f5963 98% विखंडित है, तो आपको कैसे पता चलेगा कि क्यों देखना है? यह बस नहीं किया जाना चाहिए।
SSISPissesMeOff

-3

ऊपरी-आवरण वाले संस्करण 4 UUID का उपयोग करने की कोशिश करें, जिसमें '-' (डैश) के बजाय FK और '_' (अंडरस्कोर) द्वारा पहले ऑक्टेट को शामिल किया गया है।

उदाहरण के लिए

  • FK_4VPO_K4S2_A6M1_RQLEYLT1VQYV
  • FK_1786_45A6_A17C_F158C0FB343E
  • FK_45A5_4CFA_84B0_E18906927B53

औचित्य निम्नलिखित है

  • सख्त पीढ़ी एल्गोरिथ्म => वर्दी नाम ;
  • कुंजी की लंबाई 30 वर्णों से कम है , जो कि Oracle (12c से पहले) में लंबाई सीमा का नामकरण है;
  • यदि आपकी इकाई का नाम बदलता है तो आपको अपने FK का नाम बदलने की आवश्यकता नहीं है , जैसे कि इकाई-नाम आधारित दृष्टिकोण (यदि DB तालिका का नाम बदलने के लिए समर्थन करता है);
  • एक शायद ही कभी विदेशी कुंजी बाधा के नाम का उपयोग करेगा। Eg DB टूल आमतौर पर दिखाता है कि बाधा क्या लागू होती है। क्रिप्टोकरंसी से डरने की जरूरत नहीं है, क्योंकि आप इसे "डिक्रिप्शन" के लिए उपयोग करने से बच सकते हैं।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.