पहचान कॉलम के लिए लोग "Id" नाम का उपयोग क्यों नहीं करते हैं?

Question

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

मैंने देखा है कि लोग Idतालिका के नाम के साथ उपसर्ग करने का सुझाव देते हैं , लेकिन यह सिर्फ SQL क्वेरी लिखने वाले व्यक्ति के लिए अधिक काम करने के लिए लगता है (या प्रोग्रामर यदि आप किसी ORM जैसे इकाई फ्रेमवर्क का उपयोग कर रहे हैं), विशेष रूप से लंबे तालिका नामों जैसे CustomerProductIdयाAgencyGroupAssignementId

एक तीसरे पक्ष के विक्रेता ने हमारे लिए कुछ बनाने के लिए काम पर रखा था वास्तव में Identउपयोग करने से बचने के लिए अपने सभी पहचान कॉलम का नाम दिया था Id। पहले तो मुझे लगा कि उन्होंने ऐसा किया है क्योंकि Idएक कीवर्ड था, लेकिन जब मैंने इस पर गौर किया, तो मैंने पाया कि Idएसक्यूएल सर्वर 2005 में एक कीवर्ड नहीं है, जो कि हम उपयोग कर रहे हैं।

तो लोग Idपहचान स्तंभ के लिए नाम का उपयोग न करने की सलाह क्यों देते हैं ?

संपादित करें: स्पष्ट करने के लिए, मैं यह नहीं पूछ रहा हूं कि किस नामकरण सम्मेलन का उपयोग करना है, या तर्क के लिए दूसरे पर एक नामकरण सम्मेलन का उपयोग करना है। मैं सिर्फ यह जानना चाहता हूं कि Idपहचान कॉलम नाम के लिए उपयोग न करने की सिफारिश क्यों की गई है ।

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

Comments

BF बनफाइट पहले से ही यहां: प्रोग्रामर.स्टैकएक्सचेंज .com/q/114728/5905 हममें से कई (पढ़ें: मुझे) इसमें चूसा गया ...

— gbn

क्या पहचान आईडी के नाम के रूप में "आईडी" का उपयोग करने के खिलाफ वास्तव में ऐसा कोई नियम है? ActiveRecord, रूबी पर रूबी के लिए मानक ओआरएम, कन्वेंशन द्वारा ठीक यही करता है। ar.rubyonrails.org

— 200_success

@ 200_success डेटाबेस स्तर पर, हाँ। यह डेटाबेस साइट, ORM साइट नहीं है;)

— JNK

इसके अलावा, SQL सर्वर के लिए, विशेष रूप से, dba.stackexchange.com/questions/124655/… और, विशेष रूप से, connect.microsoft.com/SQLServer/feedback/details/2178150 पर देखें

— हारून

Answer 1

तालिका नाम उपसर्ग के बहुत अच्छे कारण हैं।

विचार करें:

TableA (id int identity, stringdata varchar(max))

TableB (id int identity, stringdata varchar(max))

हम रिकॉर्ड्स DELETEसे चाहते TableAहैं जो दोनों तालिकाओं में मौजूद हैं। काफी आसान है, हम सिर्फ एक करेंगे INNER JOIN:

DELETE a
FROM 
  TableA A
INNER JOIN 
  TableB B
    ON b.id = B.id

.... और हम सभी को मिटा दिया TableA। हमने अनजाने में बी की आईडी की खुद से तुलना की - हर रिकॉर्ड का मिलान हुआ और हर रिकॉर्ड डिलीट हो गया।

यदि खेतों का नामकरण किया गया है TableAIdऔर TableBIdयह असंभव होगा ( Invalid field name TableAid in TableB)।

व्यक्तिगत रूप से मेरे पास idतालिका में नाम का उपयोग करने के साथ कोई समस्या नहीं है , लेकिन यह वास्तव में तालिका नाम (या इकाई का नाम, यदि TableAलोग तब PeopleIdठीक काम करते हैं) को गलत क्षेत्र और उड़ाने से तुलना करने से बचने के लिए इसे प्रस्तुत करने के लिए एक बेहतर अभ्यास है। कुछ तो है।

इससे यह भी स्पष्ट होता है कि बहुत से प्रश्नों के साथ फ़ील्ड कहाँ से आती है JOIN।

Comments

तो यह मूल रूप से त्रुटियों से बचाने के लिए एक नामकरण सम्मेलन है? मुझे लगता है कि प्रयोग करना बेहतर होगा begin transactionऔर प्रयोग commit transactionकरने से बेहतर होगा (इमो) एक अधिक अप्रिय नामकरण योजना

— राहेल

@ राशेल: यह 1. स्पष्टता के लिए है। 2. अनावश्यक स्तंभ उपनामों से बचें। अनुमति दें। JOIN..USING 4. उन PHP बंदरों को नाराज करें जो एकल वस्तुओं में काम करते हैं, सेट नहीं

— gbn

@ राचेल यदि आपने प्रश्न लिखते समय गलती को नोटिस नहीं किया है, और इससे पहले कि आप इसे निष्पादित करते हैं, तो इसकी संभावना है कि आप इसे करने से पहले नोटिस करेंगे। यह सामान होता है, क्यों यह अधिक संभावना है?

— एंडी १

@ और मैं हमेशा SELECTअपने रिकॉर्ड को खोजने से पहले DELETEएक काम करता हूं, और एक बार जब मैं बयान चलाता हूं, तो मैं हमेशा सत्यापित करता हूं कि पंक्ति गणना वह है जो मैं करने से पहले उम्मीद करता हूं।

— राहेल

@ राचेल यह अच्छा है कि आपके पास कुछ है जो आपके लिए काम करता है। क्या आप सभी को ऐसा कर सकते हैं?

— एंडी १

Answer 2

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

अब आपके पास CustomerAddress से ग्राहक ID का संदर्भ होना चाहिए। आप कॉलम आईडी का नाम स्पष्ट रूप से नहीं दे सकते, इसलिए आप customer_id के साथ जाएं।

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

ON c.id = ca.id

वूप्स, होना चाहिए था ON c.id = ca.customer_id। या बेहतर अभी तक, अपनी पहचान के कॉलम को विवरणात्मक रूप से नाम दें, इसलिए यह हो सकता है ON c.customer_id = ca.customer_id। फिर अगर आप गलती से कहीं गलत टेबल उपनाम का उपयोग करते हैं, तो customer_id उस तालिका में एक कॉलम नहीं होगा, और आपको खाली परिणाम और बाद में कोड स्क्वीटिंग के बजाय एक अच्छा संकलन त्रुटि मिलेगी।

दी, ऐसे मामले हैं जहां यह मदद नहीं करता है, जैसे कि यदि आपको एक टेबल से दूसरे टेबल पर कई विदेशी कुंजी संबंधों की आवश्यकता है, लेकिन सभी प्राथमिक कुंजी "आईडी" का नामकरण करने से वहां कोई मदद नहीं करता है।

Answer 3

सभी प्राथमिक कुंजियों के लिए एक सामान्य नाम का उपयोग नहीं करने के लिए सम्मेलन से प्राप्त लाभों के बारे में सभी उत्तरों का सारांश यहां दिया गया है:

• कम गलतियों, चूंकि पहचान क्षेत्रों का नाम नहीं दिया गया है

  आप गलती से एक क्वेरी नहीं लिख सकते हैं जो B.Id = B.Idइसके बजाय पर मिलती है A.Id = B.Id, क्योंकि पहचान क्षेत्रों को कभी भी सटीक नाम नहीं दिया जाएगा।

• स्पष्ट स्तंभ नाम।

  यदि आप नाम वाले कॉलम को देखते हैं CustomerId, तो आपको तुरंत पता चल जाता है कि उस कॉलम में क्या डेटा है। यदि स्तंभ का नाम कुछ सामान्य जैसा था Id, तो आपको यह जानने के लिए तालिका के नाम के साथ-साथ यह जानना होगा कि कॉलम में क्या डेटा है।

• अनावश्यक स्तंभ उपनामों से बचा जाता है

  अब आप SELECT CustomerId, ProductIdएक क्वेरी से लिख सकते हैं , जो इसके बजाय, के Customersसाथ मिलती ProductsहैSELECT Customer.Id as CustomerId, Products.Id as ProductId

• JOIN..USINGवाक्यविन्यास की अनुमति देता है

  आप Customer JOIN Products USING (CustomerId)इसके बजाय सिंटैक्स के साथ तालिकाओं में शामिल हो सकते हैंCustomer JOIN Products ON Customer.Id = Products.Id

• कुंजी खोज में खोजना आसान है

  यदि आप किसी बड़े समाधान में ग्राहक की पहचान के क्षेत्र की तलाश कर रहे हैं, तो खोज करना CustomerIdअधिक उपयोगी हैId

यदि आप किसी अन्य लाभ के बारे में सोच सकते हैं, तो इसका नामकरण सम्मेलन मुझे बताएं और मैं इसे सूची में जोड़ दूंगा।

चाहे आप पहचान क्षेत्रों के लिए अद्वितीय या समान स्तंभ नामों का उपयोग करने के लिए चुनते हैं, आप पर निर्भर है, लेकिन आप जो भी चुनते हैं, उसके अनुरूप हो :)

Answer 4

लिंक किए गए प्रश्न से मेरे उत्तर की प्रतिलिपि बनाने के लिए:

एक ऐसी स्थिति है जहां हर टेबल पर "आईडी" चिपके रहना सबसे अच्छा विचार नहीं है: USINGकीवर्ड, यदि यह समर्थित है। हम इसका उपयोग अक्सर MySQL में करते हैं।

उदाहरण के लिए, यदि आपके पास fooTableकॉलम है fooTableIdऔर barTableविदेशी कुंजी है fooTableId, तो आपके प्रश्नों का निर्माण इस प्रकार किया जा सकता है:

SELECT fooTableId, fooField1, barField2 FROM fooTable INNER JOIN barTable USING (fooTableId)

यह न केवल टाइपिंग को बचाता है, बल्कि विकल्प की तुलना में बहुत अधिक पठनीय है:

SELECT fooTable.Id, fooField1, barField2 FROM fooTable INNER JOIN barTable ON (fooTable.Id = barTable.foTableId)

Answer 5

अतिरेक को सीमित करने के लिए एक डेटाबेस स्कीमा को सामान्य करने के बाद, टेबल को स्थापित संबंधों (एक से एक, एक से कई, कई से कई) के साथ छोटे तालिकाओं में विभाजित किया जाता है। प्रक्रिया में मूल तालिका में एकल फ़ील्ड एकाधिक सामान्यीकृत तालिकाओं में दिखाई दे सकती हैं।

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

| Author_Nickname | Author_Email | Post_Title | Post_Body |
+-----------------+--------------+------------+-----------+
| dave            | [e-mail]   | Blah       | Bla bla   |
| dave            | [e-mail]   | Stuff      | I like    |
| sophie          | [e-mail]     | Lorem      | Ipsum     |

इसे सामान्य करने से दो तालिकाओं का निर्माण होगा:

लेखक:

| Author_Nickname | Author_Email |
+-----------------+--------------+
| dave            | [e-mail]   |
| sophie          | [e-mail]     |

पद

| Author_Nickname | Post_Title | Post_Body |
+-----------------+------------+-----------+
| dave            | Blah       | Bla bla   |
| dave            | Stuff      | I like    |
| sophie          | Lorem      | Ipsum     |

यहाँ Author_Nickname लेखक तालिका के लिए एक प्राथमिक कुंजी और पोस्ट टेबल में एक विदेशी कुंजी होगी। भले ही Author_Nickname दो तालिका में दिखाई देता है, यह अभी भी जानकारी की एक इकाई से मेल खाता है, अर्थात। प्रत्येक स्तंभ का नाम किसी एक क्षेत्र से मेल खाता है ।

कई मामलों में मूल क्षेत्रों पर एक अद्वितीय बाधा नहीं हो सकती है, इसलिए एक संख्यात्मक कृत्रिम क्षेत्र का उपयोग प्राथमिक कुंजी के रूप में किया जाता है। यह इस तथ्य को नहीं बदलता है कि प्रत्येक स्तंभ नाम अभी भी एक एकल फ़ील्ड का प्रतिनिधित्व करता है। पारंपरिक डेटाबेस डिज़ाइन में, व्यक्तिगत स्तंभ नाम एकल फ़ील्ड के अनुरूप होते हैं, भले ही वे कुंजी न हों। (जैसे, एक का प्रयोग करेंगे part.partname और client.clientname बजाय part.name और client.name )। यह INNER JOIN ... USING <key>और NATURAL JOINसिंटैक्स की मौजूदगी का कारण है।

लेकिन, आजकल, और ORM परतों कई भाषाओं में आसानी से उपलब्ध के साथ, डेटाबेस अक्सर OO भाषाओं के लिए एक सतत परत, जिसमें यह स्वाभाविक है कि चर है कि विभिन्न वर्गों में एक ही भूमिका ही कहा जाता है है (के रूप में तैयार कर रहे हैं part.name और client.name , part.partname और client.clientname नहीं )। ऐसे संदर्भ में, मैं अपनी प्राथमिक कुंजियों के लिए 'आईडी' का उपयोग करता हूं।

Answer 6

एक तृतीय-पक्ष विक्रेता जिसे हमने हमारे लिए कुछ बनाने के लिए काम पर रखा था, वास्तव में उनके सभी पहचान स्तंभों का नाम दिया था पहचान केवल आईडी का उपयोग करने से बचने के लिए।

"पहचान" के बजाय "पहचान" का उपयोग करना वास्तव में कुछ भी हल नहीं करता है यदि "पहचान" समाप्त होता है, तो उनके सभी तालिकाओं पर उपयोग किया जा रहा है।

Drupal साइट पर SQL कोडिंग सम्मेलनों पर एक अच्छा लेख है जो इस स्थिति के लिए एक अच्छा अभ्यास दर्शाता है:

संभावित नामस्थान टकराव को रोकने के लिए मॉड्यूल नाम के साथ तालिका नामों को उपसर्ग करना एक अच्छा अभ्यास है।

इस दृष्टिकोण से, CustomerProductId और AgencyGroupAssignmentId उपयोग करने के लिए समझ में आता है। हां, यह काफी क्रियात्मक है। आप इसे छोटा कर सकते हैं, लेकिन उसके बाद संबंधित होने के लिए सबसे बड़ा बिंदु यह है कि डेवलपर जो आपका अनुसरण करता है वह आपको समझ में आएगा या नहीं । क्रिया तालिका नामों के साथ पूर्ववर्ती Ids को अस्पष्टता नहीं छोड़नी चाहिए कि वे क्या हैं। और (मुझे) कि कुछ कीस्ट्रोक्स को बचाने से ज्यादा महत्वपूर्ण है।

Answer 7

मैं अपने कॉलम ग्राहक आईडी का नाम देता हूं, इसलिए जब भी मैं टाइप करता हूं

FROM dbo.Customers AS c JOIN dbo.CustomerOrders AS o

SQL प्रॉम्प्ट तुरंत निम्नलिखित सुझाव देता है

ON c.CustomerID = o.CustomerID 

यह मुझे कुछ कीस्ट्रोक्स बचाता है। फिर भी मुझे लगता है कि नामकरण परंपराएं बहुत व्यक्तिपरक हैं और जैसे कि मेरे पास एक या एक मजबूत राय नहीं है।

Answer 8

यह वही कारण है जिसके कारण आप अपने सभी वैरचेयर फ़ील्ड को "UserText" और "UserText1" जैसे कुछ नाम नहीं देंगे, या आप "UserDate" और "UserDate1" का उपयोग क्यों नहीं करेंगे।

विशिष्ट यदि आपके पास एक तालिका में एक पहचान क्षेत्र है तो यह आपकी प्राथमिक कुंजी है। यदि आप दोनों तालिका में प्राथमिक कुंजी आईडी थे, तो आप मूल तालिका में किसी विदेशी कुंजी के साथ एक चाइल्ड टेबल कैसे बना सकते हैं?

हर कोई इस पद्धति से सहमत नहीं है, लेकिन मेरे डेटाबेस में मैं प्रत्येक तालिका के लिए एक अद्वितीय संक्षिप्त नाम प्रदान करता हूं। उस तालिका के पीके का नाम PK_ [abbrv] ID होगा। यदि इसका उपयोग कहीं भी FK के रूप में किया जाता है तो मैं FK_ [abbrv] ID का उपयोग करूंगा। अब मुझे लगता है कि तालिका के संबंध क्या हैं, इस पर शून्य अनुमान काम करता है।

Answer 9

मूल रूप से एक ही कारण के लिए आप आमतौर पर पैरामीटर 1, पैरामीटर 2 का नाम नहीं देते हैं ... यह सटीक है, लेकिन वर्णनात्मक नहीं है। यदि आप TableId देखते हैं, तो आप संभवतः यह मान सकते हैं कि यह संदर्भ के लिए, भले ही तालिका के लिए एक pk रखने के लिए उपयोग किया जाता है।

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

संदर्भ से बाहर, आईडी को किसी तालिका की प्राथमिक कुंजी माना जा सकता है (आईडी उपयोगी नहीं है जब तक कि कोई आईडी नहीं है), लेकिन पहचान आपको (या कम से कम मुझे) यह भी नहीं बताती है। मैं अंततः यह पता लगाऊंगा कि पहचान पहचान के लिए कम है (एक तरह से या किसी अन्य), लेकिन मैंने जो समय बिताया है वह समझ से बाहर व्यर्थ होगा।

Answer 10

एक उपसर्ग का उपयोग करें ताकि प्राथमिक कुंजी और विदेशी कुंजी संदर्भों में एक ही नाम का उपयोग किया जा सके, ताकि आप प्रदर्शन कर सकें natural join/ join ... using।