डेटाबेस तालिकाओं में आईडी कॉलम का नामकरण

98

मैं डेटाबेस तालिकाओं में आईडी कॉलम के नामकरण पर लोगों की राय सोच रहा था।

अगर मेरे पास एक तालिका है जिसमें एक पहचान कॉलम की प्राथमिक कुंजी के साथ चालान कहा जाता है, तो मैं उस स्तंभ को चालानडॉइड कहूंगा ताकि मैं अन्य तालिकाओं के साथ संघर्ष न करूं और यह स्पष्ट है कि यह क्या है।

जहां मैं कार्यशील वर्तमान हूं, उन्होंने सभी आईडी कॉलम आईडी कहे हैं।

तो वे निम्नलिखित कार्य करेंगे:

Select  
    i.ID 
,   il.ID 
From
    Invoices i
    Left Join InvoiceLines il
        on i.ID = il.InvoiceID

अब, मुझे यहाँ कुछ समस्याएँ दिखाई दे रही हैं:
1. आपको सेलेक्ट के लिए कॉलम को उर्फ ​​करने की आवश्यकता होगी
। 2. आईडी = इनवॉइसआईडी मेरे दिमाग में फिट नहीं है।
3. यदि आपने टेबल को उर्फ ​​नहीं किया है और इनवॉयसआईडी को संदर्भित किया है, तो यह स्पष्ट है कि टेबल क्या है यह चालू है?

विषय पर अन्य लोगों के विचार क्या हैं?

sql  naming-conventions 
— arry
स्रोत
1
अर्घ, हम खराब स्वाद वाले लोगों से घिरे हैं! ;-)
— विंको वर्सालोविक
— पीएचपी
2
दूसरे उत्तर को " उत्तर " के रूप में चुनने के बारे में कैसे ?
— डिस्प्लेनाम
— फिलीपिसे जुएल

जवाबों:

25

ID एक SQL Antipattern है। Http://www.amazon.com/s/ref=nb_sb_ss_i_1_5?url=search-alias%3Dstripbooks&field-keywords=sql+antipatterns&sprefix=sll+a देखें

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

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

यदि आप उपयोग करने वाले सिंटैक्स का उपयोग करना चाहते हैं जो कि कुछ dbs अनुमति देते हैं, तो आप आईडी का उपयोग नहीं कर सकते।

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

तो अब आपके पास है

select t1.field1, t2.field2, t3.field3
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t1.id = t3.table2id

जब आपका मतलब

select t1.field1, t2.field2, t3.field3 
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t2.id = t3.table2id

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

— HLGEM
स्रोत
8
@ spencer7593, सिर्फ इसलिए कि आपको आईडी पसंद है इसका मतलब यह नहीं है कि यह एक एंटीपैटर्न नहीं है। जब आप टैबलेन आईडी रखते हैं तो जॉइन में गलती करना कठिन होता है क्योंकि आपको तुरंत सिंटैक्स त्रुटि मिलती है।
— HLGEM
7
+1 कॉलम जो पर्यायवाची हैं उनका एक ही नाम होना चाहिए - तालिका नाम उपसर्ग का उपयोग करके आपके पास एक प्राथमिक कुंजी स्तंभ हो सकता है जिसे table1ID कहा जाता है और एक अन्य तालिका में एक विदेशी कुंजी स्तंभ जिसे table1ID कहा जाता है - और आप जानते हैं कि वे एक ही चीज हैं। मुझे यह 20 साल पहले सिखाया गया था और इसका एक अभ्यास जो आपको निराश नहीं करता है।
— अमेल्विन जूल
9
नहीं! यह स्मर्फिंग नामकरण सम्मेलन है!
— रॉस
19
मुझे यह सम्मेलन पसंद नहीं है क्योंकि इसका मतलब है कि आप व्यावहारिक रूप से अपनी सभी तालिकाओं को उर्फ ​​करने के लिए मजबूर हैं ताकि आप बार-बार तालिका का नामकरण नहीं कर रहे हों, तालिका का नामकरण कर रहे हों, और फिर आईडी जोड़ रहे हों। join table2 on table1.table1id = table2.table1id। आपका तर्क ठीक है सिवाय इसके कि अगर आप आईडी का उपयोग करते हैं, तो तालिका का नाम वैसे भी आईडी के सामने है। join table2 on table1.id = table2.table1id... जो सिर्फ क्रिया के रूप में है और निरर्थक नहीं है, और न ही उपनामों को अस्पष्ट करता है ताकि केवल उल्लेख किए गए अतिरेक को रोका जा सके .. जो कि मेरी राय में sql विकास का प्रतिबंध है।
— एंथर
13
फिर, यदि आपके पास एक Nameतालिका में कोई फ़ील्ड है, तो क्या आपको Table1Nameउस फ़ील्ड की समान समस्याओं से बचने के लिए इसे बदलना चाहिए ? क्या आपको एक ही कारण से तालिका नाम के साथ सभी कॉलम उपसर्ग करना चाहिए? यह सही नहीं लगता।
— जोनवो
151

मैंने हमेशा आईडी कॉलम के लिए IDN से IDName + ID और फिर विदेशी कुंजी के लिए TableName + ID को प्राथमिकता दी। इस तरह सभी तालिकाओं में आईडी फ़ील्ड के लिए एक ही नाम है और कोई अनावश्यक विवरण नहीं है। यह मुझे सरल लगता है क्योंकि सभी तालिकाओं में एक ही प्राथमिक कुंजी फ़ील्ड नाम है।

जहाँ तक तालिकाओं में शामिल होने और न जाने कौन सी Id फ़ील्ड किस तालिका की है, मेरी राय में इस स्थिति को संभालने के लिए क्वेरी लिखी जानी चाहिए। जहां मैं काम करता हूं, हम हमेशा टेबल / टेबल उपनाम के साथ एक बयान में उपयोग किए जाने वाले क्षेत्रों को रोकते हैं।

— kemiller2002
स्रोत
2
मुझे एक पुराने धागे का एहसास है लेकिन मैं सहमत हूं। डेटाकास्ट लेयर पर मैपिंग को भी आसान बनाता है: यदि सभी "ऑब्जेक्ट्स" में एक Id फ़ील्ड है जो अद्वितीय होनी चाहिए, तब डेटा एक्सेस लेयर पर विधियाँ बनाते समय ऐसी चीज़ों को डिलीट करें जैसे आप उन्हें सूची से प्राप्त कर सकते हैं क्योंकि आप उन्हें सामान्य बना सकते हैं। किसी भी चीज़ के लिए Ids और पता है कि आपको बस उस तालिका से उस आईडी = ब्लाह को हटाने की आवश्यकता है, जहां से प्रत्येक तालिका के साथ-साथ तालिका के नाम / प्रोग्राम लॉजिक नाम मैपिंग के लिए अद्वितीय होने वाली मैपिंग रखने के बजाय।
— माइक
1
केविन, आप जैसा ही। उदाहरण के लिए: user_id, PK_ के लिए role_id और FKey के लिए role_user_id। यह बड़े पैमाने पर परियोजना पर अच्छा है। क्योंकि यदि सभी आईडी फ़ील्ड को "आईडी" नाम दिया गया है, तो यह बहुत भ्रमित है। लेकिन मुझे लगता है कि यह व्यक्तिगत प्राथमिकता है, किसी को लगता है कि केवल "आईडी" का उपयोग स्पष्ट है।
— चेउंग
2
यह मेरी प्राथमिकता है। सिर्फ इसलिए कि क्रॉस टेबल क्वेश्चन पढ़ने में ज्यादा मुश्किल होते हैं इसका मतलब यह नहीं है कि इसे आसान बनाने के लिए Id कॉलम को बदल दिया जाना चाहिए। बस अपने उपनामों को अधिक वर्णनात्मक बनाएं।
— tmutton
1
मुझे संदेह है कि संस्था के नाम के साथ प्रीफिक्सिंग आईडी का कन्वेंशन जो भी कारणों से "सेलेक्ट *" का उपयोग कर लोगों से आता है। "चयन *" के प्रति सहिष्णु वातावरण में, वास्तविकता आमतौर पर हर जगह से हर चीज के थोक चयन का समर्थन करने के लिए विकृत हो जाती है। यदि आप आँख बंद करके सब कुछ का चयन नहीं करते हैं, तो इसका कोई मतलब नहीं है। USING और प्राकृतिक जुड़ाव के संदर्भ भी हैं, जो काफी खतरनाक हैं, और मेरे लिए एक तर्क की तरह बिल्कुल भी नहीं लगते क्योंकि वे प्रभावी रूप से आपको भूमिका-आधारित विदेशी कुंजी नामकरण सम्मेलन का उपयोग करने से रोकते हैं।
— रोमन पोलुनिन
53

Theres देर से मेरी कंपनी में इस बात के बारे में एक झगड़ा लड़ाई थी। LINQ के आगमन ने निरर्थक tablename + ID पैटर्न को और अधिक स्पष्ट रूप से मेरी आँखों में मूर्खतापूर्ण बना दिया है । मुझे लगता है कि अधिकांश वाजिब लोग कहेंगे कि यदि आप अपनी एसक्यूएल को इस तरह से लिख रहे हैं कि आपको एफके को अलग करने के लिए तालिका के नाम निर्दिष्ट करने होंगे तो यह न केवल टाइपिंग पर एक बचत है, बल्कि यह आपके एसक्यूएल को स्पष्टता का उपयोग करता है उस आईडी को आप स्पष्ट रूप से देख सकते हैं कि कौन सा पीके है और कौन सा एफके है ।

उदाहरण के लिए

कर्मचारियों से लेफ्टिनेंट में शामिल हों और c.EmployeeID पर ग्राहक शामिल हों

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

— Echostorm
स्रोत
2
सिवाय आपके उदाहरण के लिखने के लिए मैंने अपने जीवन में एक भी डेवलपर को कभी नहीं जाना। इसके बजाए वे लिखते हैं: LEFT JOIN कस्टमर्स as c on e.ID = c.EmployeeID मेरे लिए, यह स्पष्ट है: LEFT JOIN कस्टमर्स as c on e.EmployeeID = c.EmployeeID और कौन सा आइटम टेबल नाम से स्पष्ट है । स्पष्ट रूप से customer.employeeId एक विदेशी कुंजी है जबकि कर्मचारी .employId नहीं है।
— dallin
7
लोगों के एलओटी (जैसे रिपोर्ट लेखक जो बहुत जटिल एसक्यूएल लिखते हैं) और बीआई विशेषज्ञ जो आयात और निर्यात करते हैं, उन्हें अभी भी एसक्यूएल को हस्तलिखित करने की आवश्यकता है। डेटाबेस डिजाइन के लिए उन्हें भी आवेदन डेवलपर्स नहीं बस के साथ रहना है।
— एचएलजीईएम
30

हम उपयोग करते हैं InvoiceID, नहीं ID। यह प्रश्नों को अधिक पठनीय बनाता है - जब आप IDअकेले देखते हैं तो इसका मतलब कुछ भी हो सकता है, खासकर जब आप तालिका को अन्य नाम देते हैं i।

— जेसन कोहेन
स्रोत
सहमत हैं, और आप मुख्य कारण "आईडी" का उपयोग नहीं करते हैं, क्योंकि हमारे पास हमेशा टेबल उर्फ ​​जैसे "आई" इनॉयस, पी फॉर "प्रोडक्ट" ऑन एसक्यूएल या लिनक्यू आदि
— चेउंग
2
Id का उपयोग करना अधिक उचित है। कॉलम "इनवॉइस" तालिका में है, इसलिए यह पर्याप्त होना चाहिए। यदि आप क्रॉस टेबल क्वेश्चन लिख रहे हैं तो आपको अधिक वर्णनात्मक उपनामों का उपयोग करना चाहिए। "मैं" पर्याप्त नहीं है। इसे "चालान" कहें।
— tmutton
1
यह स्पष्ट नहीं है कि अकेले "आईडी" का मतलब चालान है। मान लीजिए कि आपको खातों और लोगों को विदेशी कुंजी भी मिली है। अब कौन सी "आईडी?" क्या जॉइन करना आसान नहीं है, कहते हैं, a.ID = b.InvoiceID के बजाय a.InvoiceID = b.InvoiceID को पढ़ना और इसे आसानी से डीबग करना संभव नहीं है।
— जेसन कोहेन
22

मैं केवन और यहां कुछ अन्य लोगों से सहमत हूं कि एक मेज के लिए पीके को बस आईडी होना चाहिए और विदेशी कुंजी अन्य को सूचीबद्ध करें + आईडी।

हालांकि मैं एक कारण जोड़ना चाहता हूं जिसने हाल ही में इस तर्क को अधिक वजन दिया।

मेरी वर्तमान स्थिति में हम POCO पीढ़ी का उपयोग करके इकाई ढांचे को नियोजित कर रहे हैं। पीके के मानक नामकरण सम्मेलन का उपयोग पीके सत्यापन के साथ एक बेस पोको वर्ग के उत्तराधिकार के लिए अनुमति देता है और ऐसे तालिकाओं के लिए जो सामान्य स्तंभ नामों का एक सेट साझा करते हैं। इन तालिकाओं में से प्रत्येक के लिए PK के रूप में Tablename + Id का उपयोग करना, इनके लिए आधार वर्ग का उपयोग करने की क्षमता को नष्ट कर देता है।

बस विचार करने के लिए कुछ विषय।

— pawnrob
स्रोत
8
+1 वास्तविक दुनिया के उदाहरण के लिए कि सामान्य नामकरण कैसे विशिष्ट मामले में कोड के पुन: उपयोग में सुधार करता है (क्योंकि बहुत सारे डेवलपर्स परवाह करेंगे क्योंकि लाखों .NET देवता हैं, और कई ईएफ का उपयोग करेंगे)।
— कोडिंगआउटलाउड
सिर्फ ईएफ और मेरे काम की तरह ही हमारे पास बहुत सारे सामान्य तरीके नहीं हैं। इसलिए एक webservice में कुछ ऐसा होगा जैसे सूची <परिणाम> सहेजें <T> (सूची <int> Ids); चूँकि हम जानते हैं कि हर तालिका में एक Id कॉलम होता है जो प्राथमिक कुंजी है जो हम इस तरह से कर सकते हैं कि सी # वस्तुओं की एक साधारण मैपिंग के साथ उनकी तालिकाओं के लिए (कुछ ऐसा <ग्राहक, "ग्राहक">, <BillingCode, "BillingCodes"> या बेहतर अभी तक संग्रहित नाम), पारित किए गए ऑब्जेक्ट के आधार पर मक्खी पर sql उत्पन्न करते हैं और प्रत्येक प्रकार की वस्तु के लिए कोई दोहराया बचाने / हटाने / संपादित करने के लिए वॉयला नहीं है।
— माइक
11

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


I.ID का चयन करें , il.ID इनवॉइस से बायाँ सम्मिलित करें InvoiceLines il पर i.ID = il.InvoiceID

मैं ऐसा क्यों नहीं कर सकता?

Select  
    Invoices.ID 
,   InvoiceLines.ID 
From
    Invoices
    Left Join InvoiceLines
        on Invoices.ID = InvoiceLines.InvoiceID

मेरी राय में यह बहुत पठनीय और सरल है। I और il के रूप में नामकरण चर सामान्य रूप से एक खराब विकल्प है।

— bjdodo
स्रोत
10

यह वास्तव में महत्वपूर्ण नहीं है, आप सभी नामकरण सम्मेलनों में सिमालर समस्याओं में भाग लेने की संभावना है।

लेकिन यह सुसंगत होना महत्वपूर्ण है ताकि आपको हर बार क्वेरी लिखते समय टेबल परिभाषाओं को न देखना पड़े।

— निर
स्रोत
8

मैंने बस एक ऐसी जगह पर काम करना शुरू किया जो केवल "आईडी" का उपयोग करता है (कोर टेबल में, विदेशी कुंजियों में TableNameID द्वारा संदर्भित), और पहले से ही इसके कारण सीधे TWO उत्पादन समस्याओं का पता चला है।

एक मामले में क्वेरी का उपयोग किया गया "... जहाँ ID इन (SELECT ID FROM OtherTable ..." के बजाय "... जहाँ ID in (सेलेक्ट ट्रांज़िट फ्रॉम अदरटेबल ...)।

क्या कोई भी ईमानदारी से कह सकता है कि यदि पूर्ण, सुसंगत नामों का उपयोग करना आसान नहीं होता है, तो गलत कथन का उपयोग किया जाता है जहां "... जहां TransID in (OtherTableID से अन्य का चयन करें ...)? मुझे नहीं लगता? इसलिए।

कोड को रीफ़ैक्‍ट करने पर दूसरा समस्‍या होता है। यदि आप एक अस्थायी तालिका का उपयोग करते हैं, जबकि पहले क्वेरी एक कोर तालिका से चली गई थी, तो पुराना कोड "... dbo.MyFunction (t.ID) ..." और यदि परिवर्तित नहीं हुआ है, लेकिन "t" अब एक को संदर्भित करता है मुख्य तालिका के बजाय अस्थायी तालिका, आपको एक त्रुटि भी नहीं मिलती है - बस गलत परिणाम।

यदि अनावश्यक त्रुटियां उत्पन्न करना एक लक्ष्य है (शायद कुछ लोगों के पास पर्याप्त काम नहीं है?), तो इस तरह का नामकरण सम्मेलन महान है। अन्यथा लगातार नामकरण जाने का रास्ता है।

— एरिक कासन
स्रोत
3
+1 वास्तविक दुनिया उदाहरण के लिए और अधिक विशिष्ट नाम बनाए रखने में सुधार।
— कोडिंगआउटलाउड
6

सादगी के लिए ज्यादातर लोग स्तंभ का नाम आईडी पर रखते हैं। यदि इसके पास किसी अन्य तालिका पर एक विदेशी कुंजी संदर्भ है, तो वे अन्वेषण को जॉइन के मामले में इनवॉइस (आपके उदाहरण का उपयोग करने के लिए) कहते हैं, आप वैसे भी तालिका को अलियास कर रहे हैं, इसलिए स्पष्ट inv.ID अभी भी inv.InvoidID की तुलना में सरल है।

— माइकल ब्राउन
स्रोत
6

मैं व्यक्तिगत रूप से पसंद करते हैं (जैसा कि ऊपर कहा गया है) Table.ID के लिए पी और TableID के लिए FK । यहां तक ​​कि (कृपया मुझे गोली मत चलाना) Microsoft Access यह अनुशंसा करता है।

फिर भी, मुझे यह भी पता है कि कुछ उत्पन्न करने वाले उपकरण PK के लिए TableID का पक्ष लेते हैं क्योंकि वे सभी कॉलम नाम को लिंक करते हैं , जिसमें शब्द 'ID' शामिल होता है , जिसमें ID शामिल होता है !!!

यहां तक ​​कि क्वेरी डिज़ाइनर Microsoft SQL सर्वर पर भी ऐसा करता है (और आपके द्वारा बनाई गई प्रत्येक क्वेरी के लिए, आप कॉलम आईडी पर सभी तालिकाओं पर सभी अनावश्यक नव निर्मित संबंधों को बंद कर देते हैं)

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

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

  • तालिका का नाम: बहुवचन। पूर्व। कर्मचारियों

  • तालिका उपनाम: पूर्ण तालिका नाम, एकवचन। पूर्व।

    SELECT Employee.*, eMail.Address
FROM Employees AS Employee LEFT JOIN eMails as eMail on Employee.eMailID = eMail.eMailID -- I would sure like it to just have the eMail.ID here.... but oh well

[अपडेट करें]

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

— percebus
स्रोत
मुझे लगता है कि आपकी बात डेटाबेस की सुंदरता और उपदेशात्मक उद्देश्यों के लिए अच्छी है, लेकिन कार्यक्षमता के लिए मुझे लगता है कि यह एक समस्या है। बहुवचन तालिका के नाम तालिकाओं और पीके आईडी के बीच असंगतता को बढ़ावा देता है <-> FK IdTable एक ही चीज के नाम पर भिन्नताएं बनाता है। इसी समय, User.UserIdप्रोग्रामिंग में टाइप करने के लिए थोड़े अजीब तरह का है।
— मचाडो
4

औपचारिक डेटा शब्दकोश के दृष्टिकोण से इस पर आते हुए, मैं डेटा तत्व का नाम दूंगा invoice_ID। आम तौर पर, एक डेटा तत्व नाम डेटा शब्दकोश में अद्वितीय होगा और आदर्श रूप में पूरे नाम का एक ही नाम होगा, हालांकि कभी-कभी अतिरिक्त योग्यता शर्तों को संदर्भ के आधार पर आवश्यक हो सकता है जैसे नाम वाले डेटा तत्व employee_IDको ऑर्गन चार्ट में दो बार इस्तेमाल किया जा सकता है और इसलिए के रूप में योग्य है। supervisor_employee_IDऔर subordinate_employee_IDक्रमशः।

जाहिर है, नामकरण परंपराएं व्यक्तिपरक और शैली का विषय हैं। मुझे एक उपयोगी प्रारंभिक बिंदु होने के लिए आईएसओ / आईईसी 11179 दिशानिर्देश मिले हैं।

डीबीएमएस के लिए, मैं टेबल को एंटाइट्स के संग्रह के रूप में देखता हूं (उन लोगों को छोड़कर, जिनमें कभी केवल एक पंक्ति होती है जैसे कॉफिग टेबल, कॉन्स्टेंट की तालिका, आदि) उदाहरण के लिए टेबल जहां मेरी employee_IDकुंजी है Personnel। तो सीधे TableNameIDसम्मेलन मेरे लिए काम नहीं करता है।

मैंने TableName.ID=PK TableNameID=FKबड़े डेटा मॉडल पर उपयोग की जाने वाली शैली देखी है और मुझे यह कहना है कि मैं इसे थोड़ा भ्रमित करता हूं: मैं बहुत पसंद करता हूं कि एक पहचानकर्ता का नाम समान हो अर्थात वह नाम नहीं बदलता है जिसके आधार पर यह दिखाई देने वाली तालिका के आधार पर होता है। उक्त शैली का उपयोग उन दुकानों में किया जाता है जो विदेशी कुंजियों में प्राकृतिक और मिश्रित कुंजियों को ढालते हुए हर मेज पर एक IDENTITY(ऑटो-इंक्रीमेंट) कॉलम जोड़ते हैं । उन दुकानों में न तो औपचारिक डेटा शब्दकोश होते हैं और न ही डेटा मॉडल से निर्माण होता है। फिर से, यह केवल शैली का सवाल है और एक जिसकी मैं व्यक्तिगत रूप से सदस्यता नहीं लेता हूं। तो आखिरकार, यह मेरे लिए नहीं है।

उस सभी ने कहा, मैं कभी-कभी कॉलम नाम से क्वालीफायर छोड़ने के लिए एक मामला देख सकता हूं जब तालिका का नाम ऐसा करने के लिए एक संदर्भ प्रदान करता है जैसे कि नाम वाला तत्व employee_last_nameबस तालिका last_nameमें बन सकता है Personnel। तर्क है कि यहाँ डोमेन 'लोगों की अंतिम नाम' है और अधिक होने की संभावना की जा रही है है UNIONके साथ एड last_nameस्तंभों से के बजाय एक विदेशी कुंजी के रूप में इस्तेमाल किया जा अन्य तालिकाओं में , फिर एक और मेज, लेकिन फिर ... मैं बस अपना मन बदल सकता है कभी-कभी आप कभी नहीं बता सकते। यह बात है: डेटा मॉडलिंग भाग कला, भाग विज्ञान है।

— onedaywhen
स्रोत
2

मुझे लगता है कि जब तक आप सुसंगत हैं आप "आईडी" के लिए कुछ भी उपयोग कर सकते हैं। तालिका का नाम शामिल करना महत्वपूर्ण है। मैं नामकरण सम्मेलनों और मानकों को लागू करने के लिए इरविन जैसे एक मॉडलिंग टूल का उपयोग करने का सुझाव दूंगा ताकि प्रश्न लिखते समय तालिकाओं के बीच मौजूद रिश्तों को समझना आसान हो।

पहले कथन से मेरा क्या अभिप्राय है, ID के बजाय आप 'recno' जैसी किसी अन्य चीज़ का उपयोग कर सकते हैं। तो फिर इस तालिका में इनवॉइस का एक PK_recno और इसी तरह होगा।

चीयर्स, बेन

2

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

 Select Invoice.InvoiceID, Lines.InvoiceLine, Customer.OrgName
 From Invoices Invoice
 Join InvoiceLines Lines on Lines.InvoiceID = Invoice.InvoiceID
 Join Customers Customer on Customer.CustomerID = Invoice.CustomerID

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

— रोब एलन
स्रोत
1

डेटाबेस में कॉलम नाम के लिए, मैं "इनवॉइसआईडी" का उपयोग करूंगा।

यदि मैं LINQ के माध्यम से खेतों को एक अनाम संरचना में कॉपी करता हूं, तो मैं इसे "आईडी" नाम दे सकता हूं, अगर यह संरचना का एकमात्र आईडी है।

यदि स्तंभ का उपयोग किसी विदेशी कुंजी में नहीं किया जा रहा है, तो इसका उपयोग केवल संपादन संपादित करने या हटाने के लिए एक पंक्ति को विशिष्ट रूप से पहचानने के लिए किया जाता है, मैं इसे "PK" नाम दूंगा।

— जेम्स क्यूरन
स्रोत
1

यदि आप प्रत्येक कुंजी को एक अनूठा नाम देते हैं, उदाहरण के लिए "invoices.id" के बजाय "invoices.invoice_id", तो आप "नेचुरल जॉइन" और "ऑपरेटर" का उपयोग बिना किसी चिंता के कर सकते हैं। उदाहरण के लिए

SELECT * FROM invoices NATURAL JOIN invoice_lines
SELECT * FROM invoices JOIN invoice_lines USING (invoice_id)

के बजाय

SELECT * from invoices JOIN invoice_lines
    ON invoices.id = invoice_lines.invoice_id

SQL अधिक वर्बोज़ बनाए बिना क्रिया को पर्याप्त बनाता है।

— स्टीवन हुआविग
स्रोत
क्या आप जानते हैं कि SQL सर्वर नेचुरल जॉइन का समर्थन करता है?
— Arry
मुझे नहीं लगता कि यह करता है। Connect.microsoft.com/SQLServer/feedback/… के अनुसार, ऐसा प्रतीत होता है कि SQL Server 2005 के बाद कुछ वर्जन में सिंटैक्स को जोड़ा जाना है। मुझे पता है कि यह PostgreSQL और Oracle में काम करता है।
— स्टीवन हुआविग
7
कभी नहीं, कभी नहीं, कभी भी प्राकृतिक जुड़ाव का उपयोग न करें। यदि एक तालिका में वर्णन फ़ील्ड है जब आप क्वेरी लिखते हैं तो आप ठीक हैं। यदि बाद में, कोई अन्य फ़ील्ड में वर्णन फ़ील्ड जोड़ता है, तो आप उस पर भी शामिल होना शुरू कर देंगे और पूरी तरह से विराम ले लेंगे।
1
हे, जो वास्तविक जीवन के अनुभव की आवाज़ की तरह लगता है :)
— डैलेंड
मैं केवल तदर्थ प्रश्नों के लिए प्राकृतिक जुड़ाव का उपयोग करूंगा।
— स्टीवन हुआविग
1

मैं चीजों को खुद के लिए सुसंगत रखने के लिए क्या करता हूं (जहां एक तालिका में एकल स्तंभ प्राथमिक कुंजी आईडी के रूप में उपयोग की जाती है) तालिका की प्राथमिक कुंजी का नाम है Table_pk। कहीं भी मेरे पास उस टेबल प्राथमिक कुंजी की ओर इशारा करते हुए एक विदेशी कुंजी है, मैं कॉलम को कॉल करता हूं PrimaryKeyTable_fk। इस तरह से मुझे पता है कि यदि मेरे पास Customer_pkमेरी ग्राहक तालिका में और Customer_fkमेरे आदेश तालिका में है, तो मुझे पता है कि आदेश तालिका ग्राहक तालिका में प्रविष्टि का उल्लेख कर रही है।

मेरे लिए, यह विशेष रूप से जुड़ने के लिए समझ में आता है, जहां मुझे लगता है कि यह आसान पढ़ता है।

SELECT * 
FROM Customer AS c
    INNER JOIN Order AS c ON c.Customer_pk = o.Customer_fk
— इयान एंड्रयूज
स्रोत
1

एफडब्ल्यूआईडब्ल्यू, हमारा नया मानक (जो बदलता है, उह, मेरा मतलब है "विकसित", हर नई परियोजना के साथ) है:

  • लोअर केस डेटाबेस फ़ील्ड नाम
  • अपरकेस टेबल नाम
  • फ़ील्ड नाम में अलग शब्दों के लिए अंडरस्कोर का उपयोग करें - इन्हें कोड में पास्कल केस में बदलें।
  • pk_ उपसर्ग का अर्थ है प्राथमिक कुंजी
  • _id प्रत्यय का अर्थ है एक पूर्णांक, ऑटो-वृद्धि आईडी
  • fk_ उपसर्ग का अर्थ है विदेशी कुंजी (कोई आवश्यक प्रत्यय नहीं)
  • _VW विचारों के लिए प्रत्यय
  • is_ बूलियन के लिए उपसर्ग

तो, एक मेज नामित नाम फ़ील्ड हो सकता है pk_name_id, first_name, last_name, is_alive,और fk_companyऔर एक दृश्य कहा जाता LIVING_CUSTOMERS_VWहै, जैसे परिभाषित:

First_name, last_name चुनें
से संपर्क करें। नाम
कहां (is_alive = 'True')

जैसा कि अन्य लोगों ने कहा है, हालांकि, किसी भी योजना के बारे में तब तक काम करेगा जब तक यह सुसंगत है और अनावश्यक रूप से आपके अर्थों को नहीं मानता है।

— CMPalmer
स्रोत
0

मैं निश्चित रूप से आपके द्वारा दिए गए कारणों के लिए आईडी फ़ील्ड नाम में तालिका नाम सहित सहमत हूं। आम तौर पर, यह एकमात्र क्षेत्र है जहां मैं तालिका का नाम शामिल करूंगा।

— DOK
स्रोत
0

मुझे प्लेन आईडी नाम से नफरत है। मैं दृढ़ता से हमेशा इनवॉइस_एड या वैरिएंट का उपयोग करना पसंद करता हूं। मुझे हमेशा पता है कि आईडी के लिए कौन सी तालिका आधिकारिक तालिका है जब मुझे आवश्यकता होती है, लेकिन यह मुझे भ्रमित करता है

SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceID = inv.ID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceLineID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceLineID = inv.ID

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

— विन्को वर्सलोविक
स्रोत
1
मैंने इस पोस्ट में बहुत बार "इनवॉइस" शब्द पढ़ा है। अब यह मजेदार लग रहा है
— केविन
2
ऊ, निहितार्थ जुड़ता है! मैं अपनी आंखें फाड़कर देखना चाहता हूं।
— HLGEM
0

मैं DomainName पसंद करता हूँ || 'आईडी'। (अर्थात DomainName + ID)

DomainName अक्सर होता है, लेकिन हमेशा नहीं, TableName जैसा ही।

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

DomainName & ID का उपयोग विदेशी कुंजी के साथ-साथ प्राथमिक कुंजी के नाम के लिए किया जा सकता है। जब foriegn कुंजियों का नाम उस कॉलम के नाम पर रखा जाता है जिसका वे संदर्भ देते हैं, तो वह एमनेमिक सहायता हो सकती है। औपचारिक रूप से, कुंजी के संदर्भ में किसी विदेशी कुंजी के नाम को बांधना आवश्यक नहीं है, क्योंकि संदर्भात्मक अखंडता संदर्भ को स्थापित करेगी। लेकिन जब यह प्रश्नों और अपडेटों को पढ़ने की बात आती है, तो यह बहुत ही आसान है।

कभी-कभी, डोमेननाम || 'आईडी' का उपयोग नहीं किया जा सकता है, क्योंकि एक ही नाम के साथ एक ही तालिका में दो कॉलम होंगे। उदाहरण: Employees.EmployeeID और Employees.SupervisorID। उन मामलों में, मैं भूमिकानाम का उपयोग करता हूं || 'आईडी', उदाहरण के रूप में।

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

— वाल्टर मिती
स्रोत
0

प्रत्येक तालिका के लिए मैं एक पेड़ पत्र आशुलिपि (उदाहरण के लिए कर्मचारी => कर्मचारी) चुनता हूं

इस तरह एक संख्यात्मक ऑटोनम्बर प्राइमरी कुंजी nkEmp बन जाती है ।

यह पूरे डेटाबेस में छोटा, अनोखा है और मैं इसके गुणों को एक नज़र में जानता हूँ।

मैं SQL और सभी भाषाओं में एक ही नाम रखता हूं (ज्यादातर C #, जावास्क्रिप्ट, VB6)।

— pkario
स्रोत
0

नामकरण तालिकाओं और स्तंभों के एक सुविचारित प्रणाली के लिए इंटरकट साइट के नामकरण सम्मेलनों को देखें । विधि प्रत्येक तालिका ( _prdउत्पाद तालिका के लिए, या _ctgश्रेणी तालिका के लिए) के लिए एक प्रत्यय का उपयोग करती है और किसी दिए गए तालिका में प्रत्येक स्तंभ के लिए अपील करती है। तो उत्पाद तालिका के लिए पहचान कॉलम होगाid_prd डेटाबेस में अद्वितीय ।

वे विदेशी कुंजियों को समझने में मदद करने के लिए एक कदम आगे जाते हैं: उत्पाद तालिका में विदेशी कुंजी जो श्रेणी तालिका को संदर्भित करती है idctg_prdताकि यह स्पष्ट हो जाए कि यह किस तालिका से संबंधित है ( _prdप्रत्यय) और यह किस तालिका (श्रेणी) से संबंधित है ।

लाभ यह है कि अलग-अलग तालिकाओं में पहचान कॉलम के साथ कोई अस्पष्टता नहीं है, और आप एक नज़र में बता सकते हैं कि कॉलम के नाम से कोई क्वेरी किस स्तंभ का उल्लेख कर रही है।

— flamingLogos
स्रोत
-2

आप निम्नलिखित नामकरण सम्मेलन का उपयोग कर सकते हैं। इसके दोष हैं लेकिन यह आपकी विशेष समस्याओं को हल करता है।

  1. तालिका के नाम के लिए लघु (3-4 अक्षर) उपनामों का उपयोग करें, अर्थात चालान - inv, चालान -invl
  2. उन उपनाम का उपयोग कर, यानी तालिका में कॉलम नाम inv_id,invl_id
  3. invl_inv_idनामों के लिए संदर्भ कॉलम का उपयोग करें ।

इस तरह से आप कह सकते हैं

SELECT * FROM Invoice LEFT JOIN InvoiceLines ON inv_id = invl_inv_id
— इल्या कोचेतोव
स्रोत
5
Ick! मैं तालिकाओं (या किसी अन्य वस्तु) के लिए छोटे उपनामों का उपयोग करने के खिलाफ मतदान करूंगा। उपनामों के साथ, आपको कभी पता नहीं चलेगा कि संक्षिप्त नाम क्या है। याद रखें, गलत तरीके से वर्तनी के कई तरीके हैं; इसे ठीक करने का केवल एक ही तरीका है।
— जेम्स क्यूरन
1
जेम्स, मैं असहमत हूं। यदि आपके पास एक छोटा नाम है जो वर्णनात्मक नहीं है और आप यह नहीं याद रख सकते हैं कि यह क्या है, तो आपने गलत नाम चुन लिया है या किसी अन्य व्यक्ति के नामकरण सम्मेलन को नहीं समझते हैं।
— kemiller2002
2
समान प्रभाव प्राप्त करने के लिए उपनाम का उपयोग करें। इनवॉइस इनवॉइस में से * सेलेक्ट करें। इनवॉयललाइंस इनवैल पर शामिल हों। inv.ID = invl.InvoiceID
— yfeldblum
2
नहीं नहीं नहीं नहीं। क्वेरी में एक शिकायत के साथ तालिका को अन्य नाम दें। लेकिन तालिका का नाम पूर्ण होना चाहिए।
— मेष
2
क्यों इतने सारे प्रोग्रामर आलसी हैं और हर चीज का जवाब कम से कम टाइप करना संभव है, क्योंकि इसका थोड़ा ज्यादा टाइप करना मुश्किल है।
— एम.पी.
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.