डेटाबेस, टेबल और कॉलम नामकरण परंपराएं? [बन्द है]

Question

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

1. क्या टेबल के नाम बहुवचन होने चाहिए?
2. क्या कॉलम के नाम विलक्षण होने चाहिए?
3. क्या मुझे टेबल या कॉलम उपसर्ग करना चाहिए?
4. क्या मुझे वस्तुओं के नामकरण में किसी भी मामले का उपयोग करना चाहिए?

क्या किसी डेटाबेस में वस्तुओं के नामकरण के लिए कोई अनुशंसित दिशानिर्देश हैं?

Comments

मुझे लगता है कि हमें स्तंभों के लिए टेबल्स और एकवचन का नाम देना चाहिए।

— अ

मुझे कई मदों के साथ "संग्रहण" के रूप में एक तालिका दिखाई देती है, एकल "संस्था" नहीं है इसलिए मैं इसे बहुवचन नाम देता हूं। जब मैं ऑब्जेक्ट्स में टेबल मैप करता हूं, तो मैं ऑब्जेक्ट्स को एकवचन में नाम दूंगा। यह सिर्फ मेरी निजी राय है।

— डीपीपी

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

— 23

इस जवाब पर एक नजर ।

— प्रदर्शन

Answer 1

मैं Microsoft के SQL सर्वर नमूना डेटाबेस की जाँच करने की सलाह देता हूं: https://github.com/Microsoft/sql-server-samples/releases/tag/advtworks

AdventureWorks नमूना डेटाबेस ऑब्जेक्ट्स के संगठन के लिए स्कीमा नामों का उपयोग करने वाले एक बहुत स्पष्ट और सुसंगत नामकरण सम्मेलन का उपयोग करता है।

1. तालिकाओं के लिए एकवचन नाम
2. स्तंभों के लिए एकवचन नाम
3. तालिका उपसर्ग के लिए स्कीमा का नाम (उदाहरण: स्कीमनाम। टेबल नाम)
4. पास्कल आवरण (उर्फ ऊपरी ऊंट का मामला)

Comments

wilsonmar.com/sql_advtworks.htm एडवेंचरवर्क्स स्कीमा का एक उत्कृष्ट विश्लेषण है।

— डैनियल ट्रेबिएन

मैं किसी भी मानक के लिए Microsoft पर भरोसा नहीं करूंगा - यदि आप उनके नॉर्थविंड डेटाबेस को देखते हैं, तो आप देखेंगे कि वे बहुवचन तालिकाओं, एकवचन स्तंभ नामों, तालिकाओं के लिए स्कीमा उपसर्गों, प्राथमिक प्रमुख स्तंभों के लिए तालिका उपसर्ग, हंगेरियन-एस्सेंस्ट कॉन्स्ट्रेन्थ उपसर्ग और सबसे खराब सभी SPACES "" बहु-शब्द तालिका नामों के लिए। इसके अतिरिक्त SQLServer के लिए सिस्टम टेबल प्लुरल्स का उपयोग करते हैं ताकि ऐसा लगता है कि एडवेंचरवर्क्स इस गुच्छा में काली भेड़ थे।

— मार्कस पोप

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

— जेसन

यह भी विचार करें कि ज्वार किस दिशा में जा रहा है। ऐसा लगता है जैसे इसका बहुवचन तालिका नामों की दिशा में जा रहा है विशेष रूप से क्योंकि SQL सर्वर में सभी सिस्टम टेबल सभी बहुवचन हैं, और एंटिटी फ्रेमवर्क के लिए डिफ़ॉल्ट बॉक्स से बाहर बहुवचन है। यदि वह Microsoft का रुख है, तो मैं उस दिशा में जाना चाहता हूं जहां हम 20 वर्षों में होंगे। यहां तक ​​कि ओरेकल के डेटाबेस सम्मेलनों को बहुवचन तालिका नाम कहते हैं। ज़रा सोचिए कि जब इसे पेश किया गया था, तो कितने सी # डेवलपर्स को "var" कीवर्ड से नफरत थी, अब चर को परिभाषित करने के लिए इसका व्यापक रूप से स्वीकृत तरीका है।

— जेसन

@ जैस्मीन - मुझे आपकी बात दिखाई देती है, हालांकि मुझे लगता है कि आपने अनजाने में अपनी उदाहरण तालिका को नाम दिया। "TableOfInvoices" को "चालान" के लिए छोटा किया जाना चाहिए, जो कि मुझे पसंद है। आपको शायद इसके बजाय "इनवॉइसटेबल" का मतलब था, जो "इनवॉइस" को छोटा करने के लिए समझ में आता है।

— डेरेक

Answer 2

देर से जवाब यहाँ, लेकिन संक्षेप में:

1. मेरी प्राथमिकता बहुवचन है
2. हाँ
3. तालिकाएँ : * आमतौर पर * कोई उपसर्ग सर्वश्रेष्ठ नहीं है। कॉलम : नहीं।
4. दोनों टेबल और कॉलम: पास्कलकेस।

विस्तार:

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

• "[SingularOfTableName] ID" प्रारूप का उपयोग करके अपनी प्राथमिक कुंजी को नाम दें । अर्थात्, आपकी तालिका का नाम ग्राहक या ग्राहक है , प्राथमिक कुंजी ग्राहक की होनी चाहिए ।
• इसके अलावा, विदेशी कुंजियों को अलग-अलग तालिकाओं में लगातार नाम देना चाहिए । ऐसा न करने वाले को पीटना कानूनी होना चाहिए। मैं प्रस्तुत करता हूं कि परिभाषित विदेशी कुंजी बाधाएं अक्सर महत्वपूर्ण होती हैं, लगातार विदेशी कुंजी नामकरण हमेशा महत्वपूर्ण होता है
• आप डेटाबेस में आंतरिक सम्मेलन होने चाहिए । हालांकि बाद में वर्गों में तुम मुझे बहुत लचीला किया जा रहा है, देखेंगे भीतर एक डेटाबेस नामकरण बहुत अनुरूप होना चाहिए। चाहे ग्राहकों के लिए अपनी मेज कहा जाता है ग्राहकों या ग्राहक से है कि आप इसे एक ही डाटाबेस के दौरान उसी तरह से करना कम महत्वपूर्ण है। और आप अंडरस्कोर का उपयोग कैसे करें यह निर्धारित करने के लिए एक सिक्का फ्लिप कर सकते हैं, लेकिन फिर आपको उन्हें उसी तरह से उपयोग करना चाहिए । यदि आप ऐसा नहीं करते हैं, तो आप एक बुरे व्यक्ति हैं जिनके पास कम आत्मसम्मान होना चाहिए।

(२) आपको क्या करना चाहिए।

• विभिन्न तालिकाओं पर एक ही तरह के डेटा का प्रतिनिधित्व करने वाले फ़ील्ड को समान नाम दिया जाना चाहिए। एक टेबल पर जिप न हो और दूसरे पर जिपकोड हो।
• अपनी तालिका या स्तंभ नामों में शब्दों को अलग करने के लिए, PascalCasing का उपयोग करें। कैमलकास्टिंग का उपयोग करना आंतरिक रूप से समस्याग्रस्त नहीं होगा, लेकिन यह सम्मेलन नहीं है और यह मज़ेदार लगेगा। मैं एक क्षण में अंडरस्कोर को संबोधित करूंगा। (आप पुराने दिनों की तरह ALLCAPS का उपयोग नहीं कर सकते। 20 साल पहले DB2 में OBNOXIOUSTABLE.ANNOYING_COLUMN ठीक था, लेकिन अब नहीं।)
• शब्दों को छोटा या संक्षिप्त न करें। नाम छोटा और भ्रमित होने की तुलना में लंबा और स्पष्ट होना बेहतर है। अल्ट्रा-शॉर्ट नाम गहरे रंग के, अधिक बर्बर समय से एक पकड़ है। Cus_AddRef। ये क्या अजीब है? Custodial Addressee संदर्भ? ग्राहक अतिरिक्त वापसी कस्टम पता रेफ़रल?

(३) आपको क्या विचार करना चाहिए।

• मुझे वास्तव में लगता है कि आपके पास तालिकाओं के लिए बहुवचन नाम होना चाहिए; कुछ एकवचन है। तर्कों को कहीं और पढ़ें। स्तंभ नाम हालांकि विलक्षण होना चाहिए। यहां तक ​​कि अगर आप बहुवचन तालिका नामों का उपयोग करते हैं, तो तालिकाएं जो अन्य तालिकाओं के संयोजन का प्रतिनिधित्व करती हैं, एकवचन में हो सकती हैं। उदाहरण के लिए, यदि आपके पास एक प्रचार और एक आइटम तालिका है, तो एक तालिका जो किसी आइटम का प्रचार का एक हिस्सा है, वह प्रमोशन_आइटीज़ हो सकती है, लेकिन यह वैध रूप से प्रमोशन_ऐम्स भी हो सकती है, जो मुझे लगता है (एक-से-कई संबंधों को दर्शाता है)।
• अंडरस्कोर का उपयोग लगातार और किसी विशेष उद्देश्य के लिए करें। PascalCasing के साथ बस सामान्य टेबल के नाम पर्याप्त स्पष्ट होने चाहिए; आपको शब्दों को अलग करने के लिए अंडरस्कोर की आवश्यकता नहीं है। अंडरस्कोरिंग के लिए एक (या) एक साहचर्य तालिका या (बी) इंगित करने के लिए अंडरस्कोर (या तो) सहेजें, जिसे मैं अगली बुलेट में संबोधित करूंगा।
• उपसर्ग न तो अच्छा है और न ही बुरा। यह आमतौर पर सबसे अच्छा नहीं है। आपके पहले db या दो में, मैं सामान्य विषयगत समूहों के तालिकाओं के लिए उपसर्गों का उपयोग करने का सुझाव नहीं दूंगा। टेबल्स अंत में आपकी श्रेणियों को आसानी से फिटिंग नहीं करते हैं, और यह वास्तव में तालिकाओं को खोजने के लिए कठिन बना सकता है । अनुभव के साथ, आप एक प्रीफ़िक्सिंग योजना की योजना बना सकते हैं और लागू कर सकते हैं जो नुकसान से अधिक अच्छा है। मैंने एक बार db में काम किया था जहाँ डेटा टेबल tbl से शुरू हुई थी , ctbl के साथ कॉन्फिग टेबल, vew के साथ व्यू , proc का sp और udf का fn, और कुछ अन्य; यह सावधानीपूर्वक लागू किया गया था, इसलिए इसे ठीक किया गया। केवल तभी जब आपने उपसर्ग की आवश्यकता होती है जब आपके पास वास्तव में अलग-अलग समाधान होते हैं जो किसी कारण से उसी db में रहते हैं; उन्हें उपसर्ग करना तालिकाओं के समूहन में बहुत सहायक हो सकता है। विशेष स्थितियों के लिए प्रीफ़िक्सिंग भी ठीक है, जैसे कि अस्थायी टेबल के लिए जिसे आप बाहर खड़े करना चाहते हैं।
• बहुत कम ही (यदि कभी) आप स्तंभों को उपसर्ग करना चाहते हैं।

Comments

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

— HLGEM

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

— Triynko

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

— एरिक

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

— dallin

@ मेरा मतलब है कि आप नहीं जानते कि मेज CustomerIDसे प्राथमिक कुंजी है Customer, या किसी अन्य तालिका में एक विदेशी कुंजी है। यह मामूली बात है। आप गरीब नामों का उपयोग क्यों करना चाहेंगे c? CustomerID = Customer.IDइसमें बहुत स्पष्ट है कि आप देखते हैं कि आप एक प्राथमिक कुंजी के साथ एक विदेशी कुंजी में शामिल हो रहे हैं; यह बेमानी नहीं है क्योंकि दोनों पक्ष दो अलग चीजें हैं। एकल चरित्र नामकरण खराब अभ्यास IMO है।

— डेव कजिनो

Answer 3

ठीक है, जब से हम राय में वजन कर रहे हैं:

मेरा मानना ​​है कि टेबल के नाम बहुवचन होने चाहिए। तालिकाएँ संस्थाओं का एक संग्रह (एक तालिका) हैं। प्रत्येक पंक्ति एक एकल इकाई का प्रतिनिधित्व करती है, और तालिका संग्रह का प्रतिनिधित्व करती है। इसलिए मैं व्यक्ति संस्थाओं (या व्यक्तियों, जो भी आपके फैंसी लेता हूं) की एक तालिका कहूंगा।

उन लोगों के लिए जो प्रश्नों में विलक्षण "इकाई नाम" देखना पसंद करते हैं, उनके लिए मैं टेबल उपनाम का उपयोग करूंगा:

SELECT person.Name
FROM People person

LINQ का "लोगों में से एक व्यक्ति जैसा व्यक्ति चुनिए। नाम"।

2, 3 और 4 के लिए, मैं @ लार्स से सहमत हूं।

Comments

@Emtucifor: अंग्रेजी में, हम यह नहीं कहते हैं कि "उस व्यक्ति की भीड़ में वहाँ मौजूद सभी व्यक्ति को देखें!" एक विलक्षण शब्द से संदर्भित कई चीजों के साथ एक वैचारिक समस्या होने की उम्मीद की जानी है। यह न तो सामान्य है और न ही उचित है। "डेटा" असाधारण है और अक्सर इसका उपयोग पदार्थ के एक टुकड़े के संदर्भ में किया जाता है, "केक" की तरह। "क्या आप केक का एक टुकड़ा लेना पसंद करोगे?" एक टेबल "पीपल" नामकरण, क्योंकि इसमें कई व्यक्तियों की जानकारी शामिल है, इसे "व्यक्ति" नाम देने से कहीं अधिक समझ में आता है। आरओडब्ल्यू के लिए "व्यक्ति" नाम का एक डेटा वर्ग समझ में आता है, जैसे कि एकवचन स्तंभ नाम।

— त्रिवेंको

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

— त्रिवेंको

@Emtucifor: हाँ, योग्य। तालिका "पर्सनॉलकेशन" का नामकरण इसे "पीपल" नाम देने के बराबर होगा। कंट्रास्ट कि इस तरह के संग्रह को केवल "व्यक्ति" के नाम के साथ, जिसका कोई मतलब नहीं है :)

— Triynko

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

— त्रिकोको

@ जोश एम। ठीक है, न तो जिस तरह से आप जाते हैं। यदि आप मेरे रास्ते से जाते हैं तो आप "व्यक्ति" के रूप में पीपल टेबल को उर्फ ​​कर सकते हैं और सेलेक्ट व्यक्ति रख सकते हैं। नाम। समस्या सुलझ गयी। ;-)

— मैट हैमिल्टन

Answer 4

मैं तीन DBAs के साथ एक डेटाबेस सपोर्ट टीम में काम करता हूं और हमारे विचार विकल्प हैं:

1. कोई भी नामकरण मानक नहीं मानक से बेहतर है।
2. कोई "एक सच्चा" मानक नहीं है, हम सभी की प्राथमिकताएँ हैं
3. यदि पहले से ही मानक है, तो इसका उपयोग करें। एक और मानक या मौजूदा मानकों को मैला न करें।

हम तालिकाओं के लिए एकवचन नामों का उपयोग करते हैं। तालिकाओं को सिस्टम के नाम (या इसके संक्षिप्त नाम) के साथ उपसर्ग किया जाता है। यह उपयोगी है अगर सिस्टम कॉम्प्लेक्स, जैसा कि आप उपसर्ग को तार्किक रूप से तालिकाओं को एक साथ समूह में बदल सकते हैं (यानी। reg_customer, reg_booking और regadmin_limits)।

फ़ील्ड के लिए हम फ़ील्ड नामों को तालिका के उपसर्ग / एक्रोनम (यानी cust_address1) शामिल करने की अपेक्षा करेंगे और हम "कोड" के लिए _ix (PK के लिए _id, _cd "नाम के मानक सेट के उपयोग को भी प्राथमिकता देते हैं। ", _nb" संख्या "के लिए, _dt" दिनांक "के लिए)।

Foriegn कुंजी फ़ील्ड का नाम प्राथमिक कुंजी फ़ील्ड के समान होना चाहिए।

अर्थात

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

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

Comments

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

— HLGEM

निश्चित रूप से एसक्यूएल को अपठनीय बनाता है; लेकिन मुझे लगता है कि मैं अनुवाद कर सकता हूं। cust_nm होना चाहिए CUSTOMERNAME , booking_dt होना चाहिए BookingDate । reg_customer, अच्छी तरह से मुझे पता नहीं है कि क्या है।

— इयान बॉयड

@Ian। अभिप्राय यह है कि आप अपने द्वारा उपयोग किए जाने वाले नामकरण के लिए चिपके रहते हैं, और इसे लगातार बनाए रखते हैं। मैं हमेशा जानता हूं कि कोई भी दिनांक फ़ील्ड _dt है, कोई भी नाम फ़ील्ड _nm है। 'reg' एक उदाहरण है, एक "पंजीकरण" प्रणाली (बुकिंग, ग्राहक आदि) और सभी संबंधित तालिकाओं में एक ही उपसर्ग होगा। लेकिन प्रत्येक अपने स्वयं के ...

— गाइ

मैं मानता हूं कि एक विशेष मानक एक सुसंगत मानक होने जितना महत्वपूर्ण नहीं है। लेकिन कुछ मानक गलत हैं। DB2 और स्तंभ नाम जैसे CSPTCN, CSPTLN, CSPTMN, CSDLN। लोगों को सीखना चाहिए कि लंबे नामों का आविष्कार किया गया है - हम चीजों को पठनीय बनाने का जोखिम उठा सकते हैं।

— इयान बॉयड

वर्षों के दौरान, मैंने अपने द्वारा विकसित और बाज़ार में अपने टेबलों के अंत में नए कॉलम जोड़े हैं। कभी-कभी, मैं अपने कॉलमों में अंग्रेजी नामों का उपयोग करता हूं, कभी-कभी मैं स्पेनिश का उपयोग करता हूं और कभी-कभी मैं किसी और चीज के लिए कॉलम का फिर से उपयोग करता हूं, बजाय उन्हें हटाने के और एक नए कॉलम को जोड़ने के लिए एक उचित वर्णनात्मक नाम के साथ जो इसका उपयोग किया जाता है। यदि मैंने किसी अन्य व्यक्ति को मेरे कोड को हैक या रिवर्स-इंजीनियर करने की कोशिश की हो, तो मैंने अपने स्रोत कोड को OBFUSCATE करने के लिए जानबूझकर ऐसा किया था। केवल मैं इसे समझ सकता हूं, कोई और निराश हो जाएगा! .. इस तरह, उन्हें हमेशा किसी भी चीज के लिए मुझ पर भरोसा करना होगा!

— फ्रैंक आर।

Answer 5

1. नहीं। एक तालिका को उस इकाई के नाम पर रखा जाना चाहिए जिसका वह प्रतिनिधित्व करता है। व्यक्ति, न कि व्यक्ति यह है कि आप कैसे किसी एक अभिलेख का प्रतिनिधित्व करेंगे।
2. फिर से वही बात। स्तंभ FirstName वास्तव में FirstNames नहीं कहा जाना चाहिए। यह सब उस पर निर्भर करता है जो आप कॉलम के साथ प्रतिनिधित्व करना चाहते हैं।
3. नहीं।
4. हाँ। स्पष्टता के लिए इसे केस करें। यदि आपको "FirstName" जैसे कॉलम रखने की आवश्यकता है, तो आवरण को पढ़ने में आसानी होगी।

ठीक है। मेरे $ 0.02 Thats

Comments

संख्या 3 में कुछ स्पष्टता जोड़ना - उपसर्ग कॉलम नाम में मेटाडेटा को एम्बेड करने का एक तरीका है। हंगेरियन संकेतन के (अति प्रयोग) के समान कारणों के लिए किसी भी आधुनिक DB में ऐसा करने की कोई आवश्यकता नहीं होनी चाहिए।

— मार्क मैकडॉनल्ड्स

`ऑर्डर से शीर्ष 15 का चयन करें 'या' ऑर्डर से शीर्ष 15 का चयन करें '? उत्तरार्द्ध मेरी (मानव) प्राथमिकता है।

— इयान बॉयड

@ इयान बॉयड: हां: रिपोर्ट में शामिल होने के लिए टॉप 100 * से रिपोर्ट करें। R.eportID = VR.ReportID पर विजिट करें। यह सब इस बात पर निर्भर करता है कि आप इसके बारे में कैसा सोचते हैं। यदि आप कनस्तर पर नींबू की तस्वीर लगाते हैं, तो आपको पता होगा कि अंदर नींबू थे, बिना दो नींबू की आवश्यकता के, यह इंगित करने के लिए कि यह बहुवचन हो सकता है। ज़रूर, आप इसे लिखित शब्द "नींबू" के साथ लेबल कर सकते हैं। लेकिन यह सिर्फ "नींबू" हो सकता है। "नींबू" नामक संसाधन प्राप्त करने के लिए, यहां जाएं।

— एरिक

कॉलम नामों में अपरकेस का उपयोग करने के लिए $ 0.01 जोड़ें और स्तंभ नामों में अंडरस्कोर का उपयोग करने के लिए एक और $ 0.01 जोड़ें, ताकि स्तंभ के नामों को सादे दृष्टि में अंतर करना आसान हो। कुल = मेरा $ 0.02 आपको दान!

— फ्रैंक आर।

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

— ०१ बजे

Answer 6

मैं एक आईएसओ / IEC 11179 शैली के नामकरण सम्मेलन के पक्ष में हूं, यह देखते हुए कि वे निर्धारित करने के बजाय दिशानिर्देश हैं।

विकिपीडिया पर डेटा तत्व नाम देखें :

"तालिकाएँ संस्थाओं की इकाइयाँ हैं, और संग्रह के नामकरण दिशानिर्देशों का पालन करें। आदर्श रूप से, एक सामूहिक नाम का उपयोग किया जाता है: जैसे, कार्मिक। बहुवचन भी सही है: कर्मचारी। गलत नाम शामिल हैं: कर्मचारी, tblEmproee, और कर्मचारी।"

हमेशा की तरह, नियमों के अपवाद हैं उदाहरण के लिए एक तालिका जिसमें हमेशा एक पंक्ति होती है वह एक विलक्षण नाम जैसे एक कॉन्फ़िगर तालिका के साथ बेहतर हो सकती है। और संगति का अत्यधिक महत्व है: जाँच करें कि क्या आपके पास एक सम्मेलन है और यदि ऐसा है तो उसका पालन करें; यदि आप इसे पसंद नहीं करते हैं, तो एक व्यवसाय के मामले में इसे अकेला रेंजर होने के बजाय बदल दिया है।

Comments

-1: संदर्भित पाठ का ISO / IEC 11179 से कोई लेना-देना नहीं है। संदर्भित विकिपीडिया पृष्ठ पर भरोसा नहीं किया जाना चाहिए; इसके बजाय वास्तविक मानक पढ़ें ( मेटाडेटा- standards.org/11179/#A5 )

— mkadunc

@onedaywhen: मुझे विकिपीडिया पृष्ठ को सही करने के विषय के बारे में पर्याप्त जानकारी नहीं है; इसके अलावा, विकिपीडिया पृष्ठ इतना गलत नहीं है क्योंकि यह भ्रामक है - यह स्पष्ट रूप से यह नहीं कहता है कि आईएसओ / आईईसी 11179 में डेटाबेस नामकरण सम्मेलनों में शामिल हैं, यह सिर्फ यह कहता है कि "आईएसओ / आईईसी 11179 तब लागू होता है जब तालिका और कॉलम एक के भीतर होते हैं। संबंध का डेटाबेस"। यह तब नामकरण सम्मेलनों का एक उदाहरण प्रदान करता है जो संबंधपरक डेटाबेस के लिए उपयोग किया जा सकता है। यह आपको यह सोचने देता है कि उदाहरण मानक से लिया गया कुछ है, जब यह विकिपीडिया लेख के लेखक द्वारा वास्तव में बनाया गया है।

— mkadunc

Answer 7

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

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

2. यदि आप तालिका नाम के एकवचन संस्करण का उपयोग करते हैं और तालिका नाम के साथ प्राथमिक कुंजी को उपसर्ग करते हैं, तो अब आपको आसानी से प्राथमिक कोड से एक तालिका नाम या अकेले कोड के माध्यम से इसके विपरीत को निर्धारित करने का लाभ होगा। आपको इसमें तालिका नाम के साथ एक चर दिया जा सकता है, "Id" को अंत तक, और अब आपके पास अतिरिक्त क्वेरी करने के बिना, कोड के माध्यम से तालिका की प्राथमिक कुंजी है। या आप कोड के माध्यम से तालिका का नाम निर्धारित करने के लिए एक प्राथमिक कुंजी के अंत से "आईडी" काट सकते हैं। यदि आप प्राथमिक कुंजी के लिए तालिका नाम के बिना "आईडी" का उपयोग करते हैं, तो आप कोड के माध्यम से प्राथमिक कुंजी से तालिका का नाम निर्धारित नहीं कर सकते। इसके अलावा, अधिकांश लोग जो टेबल के नाम को बहुवचन में रखते हैं और टेबल के नाम के साथ उपसर्ग पीके कॉलम का उपयोग करते हैं, पीके में टेबल नाम का एकवचन संस्करण (उदाहरण के लिए स्थितियां और status_id),

3. यदि आप तालिका का नाम एकवचन बनाते हैं, तो आप उन्हें उन वर्ग नामों से मेल कर सकते हैं जिनका वे प्रतिनिधित्व करते हैं। एक बार फिर, यह कोड को सरल बना सकता है और आपको वास्तव में साफ-सुथरी चीजें करने की अनुमति दे सकता है, जैसे कि टेबल के नाम के अलावा कुछ भी नहीं होने से क्लास को तत्काल करना। यह भी सिर्फ आपके कोड को अधिक सुसंगत बनाता है, जिसके कारण ...

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

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

Answer 8

हमारी प्राथमिकता:

1. क्या टेबल के नाम बहुवचन होने चाहिए?
   कभी नहीँ। इसके संग्रह होने के तर्क तर्क देते हैं, लेकिन आप कभी नहीं जानते कि तालिका में क्या होना है (0,1 या कई आइटम)। बहुवचन नियम नामकरण को अनावश्यक रूप से जटिल बनाते हैं। 1 घर, 2 घर, चूहे बनाम चूहे, व्यक्ति बनाम लोग, और हमने किसी अन्य भाषा में भी नहीं देखा है।

   Update person set property = 'value'तालिका में प्रत्येक व्यक्ति पर कार्य करता है।
   Select * from person where person.name = 'Greg'व्यक्ति पंक्तियों का संग्रह / पंक्तियाँ देता है।

2. क्या कॉलम के नाम विलक्षण होने चाहिए?
   आमतौर पर, हाँ, सिवाय जहां आप सामान्यीकरण नियम तोड़ रहे हैं।

3. क्या मुझे टेबल या कॉलम उपसर्ग करना चाहिए?
   ज्यादातर एक मंच वरीयता। हम तालिका नाम के साथ उपसर्ग कॉलम पसंद करते हैं। हम उपसर्ग तालिका नहीं करते हैं, लेकिन हम उपसर्ग दृश्य (v_) और संग्रहीत_प्रक्रिया (sp_ या f_ (फ़ंक्शन)) करते हैं। यह उन लोगों की मदद करता है जो v_person.age को ऊपर उठाने की कोशिश करना चाहते हैं जो वास्तव में एक दृश्य में एक परिकलित फ़ील्ड है (जो वैसे भी अद्यतन नहीं किया जा सकता है)।

   यह कीवर्ड की टक्कर से बचने का एक शानदार तरीका है (delivery.from break, लेकिन delivery_from नहीं करता है)।

   यह कोड को अधिक क्रियात्मक बनाता है, लेकिन अक्सर पठनीयता में सहायक होता है।

   bob = new person()
bob.person_name = 'Bob'
bob.person_dob = '1958-12-21'
   ... बहुत पठनीय और स्पष्ट है। हालांकि यह हाथ से निकल सकता है:

   customer.customer_customer_type_id

   ग्राहक और customer_type तालिका के बीच संबंध को इंगित करता है, customer_type तालिका (customer_type_id) पर प्राथमिक कुंजी इंगित करता है और यदि आप कभी भी किसी क्वेरी को डीबग करते हुए 'customer_customer_type_id' देखते हैं, तो आप तुरंत (ग्राहक तालिका) जहां से हैं।

   या जहां आपके पास customer_type और customer_category के बीच MM संबंध हैं (केवल कुछ प्रकार कुछ श्रेणियों के लिए उपलब्ध हैं)

   customer_category_customer_type_id

   ... लंबी तरफ थोड़ी () है।

4. क्या मुझे वस्तुओं के नामकरण में किसी भी मामले का उपयोग करना चाहिए? हां - निचला मामला :), अंडरस्कोर के साथ। ये बहुत पठनीय और क्रॉस प्लेटफॉर्म हैं। साथ में 3 ऊपर यह भी समझ में आता है।

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

Comments

SELECT * FROM people AS person WHERE person.name = 'Greg'मेरे लिए सबसे स्वाभाविक लगता है।

— केनमोर

@Zuko ज्यादातर, टेबल प्राथमिक कुंजी के लिए नामकरण सम्मेलन है <table name><id>, उदाहरण के लिए PersonIDया Person_IDआदि। इसलिए, यह अधिक समझ में आता है कि आप अपने तालिकाओं को बहुवचन में नाम नहीं देते हैं क्योंकि प्रत्येक रिकॉर्ड एक अलग व्यक्ति है लोग नहीं।

— मि। ब्लॉन्ड

Answer 9

ISO 11179-5 पर एक नज़र डालें: नामकरण और पहचान के सिद्धांत आप इसे यहाँ प्राप्त कर सकते हैं: http://metadata-standards.org/11179/#11179-5

मैंने कुछ समय पहले यहां इसके बारे में ब्लॉग किया था: ISO-11179 नामकरण परंपराएं

Comments

यदि आपने यहां सारांश दिया है तो आपका उत्तर अधिक सुलभ (= बेहतर) होगा। महान सूचक, हालांकि!

— ओला एल्डो

Answer 10

मुझे पता है कि इस खेल में देर हो चुकी है, और इस सवाल का जवाब पहले से ही बहुत अच्छी तरह से दिया जा चुका है, लेकिन मैं कॉलम नामों के उपसर्ग के बारे में # 3 पर अपनी राय देना चाहता हूं।

सभी स्तंभों को एक उपसर्ग के साथ नामित किया जाना चाहिए जो उस तालिका के लिए अद्वितीय है जिसमें वे परिभाषित हैं।

उदाहरण के लिए, "ग्राहक" और "पता" को देखते हुए, क्रमशः "कस्ट" और "एड्र" के उपसर्गों के साथ चलते हैं। "ग्राहक" में "cust_id", "cust_name", आदि होंगे। "पता" में "addr_id", "addr_cust_id" (FK वापस ग्राहक), "addr_street", आदि होंगे।

जब मुझे पहली बार इस मानक के साथ प्रस्तुत किया गया था, तो मैं इसके खिलाफ मृत था; मुझे इस विचार से नफरत थी। मैं अतिरिक्त टाइपिंग और अतिरेक के बारे में सोच नहीं सका। अब मुझे इसके साथ पर्याप्त अनुभव हो गया है कि मैं कभी पीछे नहीं हटूंगा।

ऐसा करने का परिणाम यह है कि आपके डेटाबेस स्कीमा के सभी कॉलम अद्वितीय हैं। इसका एक बड़ा लाभ है, जो इसके विरुद्ध सभी तर्कों को टाल देता है (मेरी राय में, निश्चित रूप से):

आप अपना पूरा कोड आधार खोज सकते हैं और किसी विशेष कॉलम को छूने वाले कोड की प्रत्येक पंक्ति को मज़बूती से खोज सकते हैं।

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

एक और, इसका अपेक्षाकृत मामूली लाभ यह है कि जब आप स्वयं से जुड़ते हैं तो आपको केवल टेबल-अलायस का उपयोग करना पड़ता है:

SELECT cust_id, cust_name, addr_street, addr_city, addr_state
    FROM customer
        INNER JOIN address ON addr_cust_id = cust_id
    WHERE cust_name LIKE 'J%';

Comments

तब आप अब नहीं कर सकते reliably find every line of code that touches a particular column... यह बात नहीं है?

— raveren

@ रेवरेन - आप अभी भी कर सकते हैं। यदि आप सभी "Select *" करते हैं, तो इस उद्देश्य के लिए क्वेरी अप्रासंगिक है। जब / यदि बाद में, आप उस क्वेरी के परिणामों का उपयोग करते हैं, तो आपको उसके डेटा के साथ कुछ करने के लिए कॉलम नाम का उपयोग करना होगा, इसलिए यह वह जगह है जहां आपको अपने कोड के बारे में चिंता करने की आवश्यकता है, न कि एसक्यूएल स्टेटमेंट।

— ग्रेनर

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

— HLGEM

जब तक आप अपने पूरे ऐप को नॉन-ओओ लैंग्वेज में कोड नहीं कर रहे हैं, तब एक अच्छी ORM लेयर होने से यह तर्क बेमानी हो जाता है।

— एडम

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

— dallin

Answer 11

इन पर मेरी राय है:

1) नहीं, तालिका के नाम विलक्षण होने चाहिए।

हालांकि यह सरल चयन के लिए समझ में आता है ( select * from Orders) यह OO समकक्ष के लिए कम समझ में आता है (Orders x = new Orders ) के ।

DB में एक तालिका वास्तव में उस इकाई का सेट है, जब आप सेट-लॉजिक का उपयोग कर रहे हैं तो यह अधिक समझ में आता है:

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

वह अंतिम पंक्ति, जुड़ने का वास्तविक तर्क, बहुवचन तालिका नामों के साथ भ्रमित करती है।

मैं हमेशा एक उपनाम का उपयोग करने के बारे में निश्चित नहीं हूं (जैसा कि मैट का सुझाव है) यह स्पष्ट करता है।

2) वे एकवचन होना चाहिए क्योंकि वे केवल 1 संपत्ति रखते हैं

3) कभी नहीं, यदि स्तंभ का नाम अस्पष्ट है (ऊपर के रूप में जहां वे दोनों में एक स्तंभ है जिसे [कुंजी] कहा जाता है) तालिका (या उसके उपनाम) का नाम उन्हें अच्छी तरह से अलग कर सकता है। आप चाहते हैं कि क्विक टाइप करने की जल्दी हो और सरल - उपसर्ग अनावश्यक जटिलता जोड़ते हैं।

4) आप जो भी चाहते हैं, मैं CapitalCase का सुझाव दूंगा

मुझे नहीं लगता कि इनमें से किसी पर भी पूर्ण दिशानिर्देशों का एक सेट है।

जब तक आप जो भी उठाते हैं वह एप्लिकेशन या DB के अनुरूप होता है, मुझे नहीं लगता कि यह वास्तव में मायने रखता है।

Comments

बिल्ली क्या है CapitalCase?

— वीरुस्त्रीनीटाइ

@ViRuSTriNiTy वह शायद मतलबpascal case

— marctrem

कीथ, संख्या # 3 पर मैं दोनों करता हूं, और मैं असंगत हूं (लेकिन मैं पचाता हूं), लेकिन मुझे नहीं मिलता है कि जब तक यह ओवरबोर्ड नहीं है, तब तक एक वर्णनात्मक स्तंभ नाम होना बुरा है, एक तालिका के साथ, एक चर, आदि

— जॉनी

@ जॉनी यह बुरा नहीं है, जैसे कि, बस जरूरत नहीं है। आपके पास सामान क्यों नहीं है? इसके अलावा सबसे IntelliSense मुख्य रूप से नाम की शुरुआत का उपयोग करता है, इसलिए यदि आप है Product.ProductName, Product.ProductID, Product.ProductPriceआदि टाइपिंग Product.Pआप सभी पहले से जुड़ा हुआ क्षेत्रों देता है।

— कीथ

Answer 12

मेरी राय में:

1. तालिका नाम बहुवचन होना चाहिए।
2. स्तंभ नाम एकवचन होना चाहिए।
3. नहीं।
4. या तो CamelCase (मेरा पसंदीदा) या टेबल नामों और स्तंभ नामों दोनों के लिए अंडरस्कोर किया गया।

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

Comments

# 4 के बारे में, पास्कलकेस ... कैमलकेस ... स्नेक_केस ...

— एंड्रयू

Answer 13

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

जैसा कि उस पर कोई सही जवाब नहीं है, आपको कुछ समय लेना चाहिए (लेकिन बहुत अधिक नहीं) और अपने स्वयं के सम्मेलनों का चयन करें और यहां - महत्वपूर्ण हिस्सा है - इसे छड़ी।

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

बस के मामले में, यहाँ मेरे जवाब हैं:

1. हाँ। एक तालिका अभिलेखों , शिक्षकों या अभिनेताओं का एक समूह है , इसलिए ... बहुवचन।
2. हाँ।
3. मैं उनका उपयोग नहीं करता।
4. डेटाबेस जो मैं अधिक बार उपयोग करता हूं - फायरबर्ड - ऊपरी मामले में सब कुछ रखता है, इसलिए यह कोई फर्क नहीं पड़ता। वैसे भी, जब मैं प्रोग्रामिंग कर रहा होता हूं, तो मैं नामों को इस तरह से लिखता हूं कि यह पढ़ने में आसान होता है, जैसे कि रिलीज़यियर ।

Answer 14

1. निश्चित रूप से तालिका के नाम एकवचन, व्यक्ति नहीं लोग रखें
   2. मुझे भी
   3. नहीं, मैंने कुछ भयानक उपसर्ग देखे हैं, यह बताने के लिए कि टेबल (tbl_) या उपयोगकर्ता स्टोर प्रक्रिया (usp_) क्या है। इसके बाद डेटाबेस का नाम ... यह मत करो!
   4. हाँ। मैं अपने सभी तालिका नामों को PascalCase करता हूं

Comments

हे भगवान। नहीं। तालिका के नाम परिभाषा बहुवचन। यह एक संग्रह है। इसमें कई चीजें हैं। "लोगों से चयन करें"। आप एक व्यक्ति से चयन नहीं कर रहे हैं, आप कई लोगों से चयन कर रहे हैं!

— त्रिवेंको

मुझे हमेशा यह पसंद आया है कि यदि यह बहुवचन है तो चयन कथन बेहतर लगता है। SELECT id,name FROM contacts WHERE email_address LIKE '%gmail%'टेबल बहुवचन, कॉलम एकवचन। फिर हमेशा व्यक्तिगत राय की बात।

— स्कुललिफ जूल

जब आप डेटाबेस मेटाडेटा को संभाल रहे हों तो tbl, qry आदि को प्रीफ़िक्स करना बेहद उपयोगी हो सकता है, यदि आप किसी त्वरित, सरल नामकरण सम्मलेन में डेटाबेस में ऑब्जेक्ट की जाँच कर रहे हैं, तो नाटकीय रूप से समझ को गति मिल सकती है

— क्रूचन

Answer 15

नामकरण परंपराएँ विकास टीम को परियोजना के केंद्र में खोज और स्थिरता बनाए रखने की अनुमति देती हैं।

एक अच्छे नामकरण सम्मेलन को विकसित होने में समय लगता है लेकिन एक बार यह जगह होने के बाद यह टीम को एक सामान्य भाषा के साथ आगे बढ़ने की अनुमति देता है। एक अच्छा नामकरण सम्मेलन संगठित रूप से परियोजना के साथ बढ़ता है। एक अच्छा नामकरण सम्मेलन आसानी से उत्पादन में सेवा प्रबंधन - सॉफ्टवेयर जीवनचक्र के सबसे लंबे और सबसे महत्वपूर्ण चरण के दौरान परिवर्तनों का सामना करता है।

यहाँ मेरे जवाब हैं:

1. हां, जब वे ट्रेडों , प्रतिभूतियों , या समकक्षों के एक समूह को संदर्भित करते हैं, तो तालिका के नाम बहुवचन होने चाहिए उदाहरण के लिए के ।
2. हाँ।
3. हाँ। एसक्यूएल टेबल tb_ के साथ उपसर्ग किए जाते हैं, दृश्य पूर्वनिर्मित vw_ होते हैं, संग्रहीत कार्यविधियाँ उपसर्ग usp_ होती हैं और ट्रिगर उपसर्ग tg_ डेटाबेस नाम से होते हैं।
4. स्तंभ का नाम निचले मामले को अंडरस्कोर द्वारा अलग किया जाना चाहिए।

नामकरण कठिन है, लेकिन हर संगठन में कोई है जो चीजों को नाम दे सकता है और प्रत्येक सॉफ्टवेयर टीम में कोई ऐसा व्यक्ति होना चाहिए जो namings मानकों की जिम्मेदारी लेता है और यह सुनिश्चित करता है कि sec_id , sec_value और security_id जैसे नामकरण समस्याएँ हल हो जाएं , इससे पहले कि वे प्रोजेक्ट में शामिल हों। ।

तो एक अच्छे नामकरण सम्मेलन और मानकों के मूल सिद्धांत क्या हैं: -

• अपने क्लाइंट और अपने समाधान डोमेन की भाषा का उपयोग करें
• वर्णनात्मक हो
• निरतंरता बनाए रखें
• विमुख, प्रतिबिंबित और परावर्तक
• जब तक वे सभी के लिए स्पष्ट न हों, संक्षिप्ताक्षर का उपयोग न करें
• कॉलम नामों के रूप में SQL आरक्षित कीवर्ड का उपयोग न करें

Comments

तालिकाओं का संबंध परिभाषा से है। जो वास्तव में विलक्षण हैं। उपसर्ग चूसना। क्या आपको कभी तालिका को दृश्य में बदलने की आवश्यकता है या इसके विपरीत? उपसर्गों के साथ प्रयास करें। यदि यह एक दृश्य या तालिका है तो क्या फर्क पड़ता है?

— विलियम जोन्स

उपसर्ग मदद कर सकता है जहां हमारे पास दो वस्तुओं के लिए समान नाम है - जैसे फ़ंक्शन और संग्रहीत कार्यविधि। मेरे पास 'GetApproverList' नाम से एक फ़ंक्शन होगा और उसी नाम के साथ मैं एक संग्रहीत प्रक्रिया बनाना चाहूंगा जो इस फ़ंक्शन को आंतरिक रूप से कॉल करेगा। Sql एक ही नाम से दो वस्तुओं के निर्माण की अनुमति नहीं देगा।

— रविन्द्र सिंह

Answer 16

यहाँ एक लिंक है जो कुछ विकल्प प्रदान करता है। मैं एक साधारण कल्पना की तलाश कर रहा था जिसका मैं आंशिक रूप से परिभाषित एक पर भरोसा करने के बजाय अनुसरण कर सकता था।

http://justinsomnia.org/writings/naming_conventions.html

Answer 17

SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName

Comments

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

— इयान बॉयड

टाइपो: Lastnameहोना चाहिएLastName

— aminimalanimal

तालिका का नाम विलक्षण होना चाहिए: उपयोगकर्ता के बजाय उपयोगकर्ता

— AZ_

और ध्यान दें कि तालिका के नाम बहुवचन कैसे हैं; के रूप में वे पकड़ उपयोगकर्ता , नहीं उपयोगकर्ता ।

— इयान बॉयड

Answer 18

तालिका के नाम हमेशा विलक्षण होने चाहिए, क्योंकि वे वस्तुओं के एक समूह का प्रतिनिधित्व करते हैं। जैसा कि आप कहते हैं कि झुंड भेड़ के एक समूह को नामित करते हैं, या झुंड पक्षियों के एक समूह को नामित करते हैं। बहुवचन की जरूरत नहीं। जब एक तालिका नाम दो नामों की रचना है और नामकरण सम्मेलन बहुवचन में है तो यह जानना कठिन हो जाता है कि क्या बहुवचन नाम पहले शब्द या दूसरा शब्द या दोनों होना चाहिए। यह तर्क है - Object.instance, न कि Objects.instance। या TableName.column, नहीं TableNames.column (s)। Microsoft SQL केस संवेदी नहीं है, यदि ऊपरी केस अक्षरों का उपयोग दो या अधिक नामों से बना होने पर टेबल या कॉलम नामों को अलग करने के लिए, टेबल नामों को पढ़ना आसान है।

Comments

एक झुंड भेड़ का एक समूह है । एक Userहै नहीं उपयोगकर्ताओं के एक समूह।

— EricRobertBrewer

Answer 19

तालिका का नाम: यह एकवचन होना चाहिए, क्योंकि यह एक वास्तविक विश्व वस्तु का प्रतिनिधित्व करने वाली एक विलक्षण इकाई है न कि वस्तुएं, जो एकवचन है।

कॉलम नाम: यह केवल एकवचन होना चाहिए, फिर यह बताता है कि यह एक परमाणु मूल्य रखेगा और सामान्यीकरण सिद्धांत की पुष्टि करेगा। यदि फिर भी, एक ही प्रकार के गुणों की संख्या n है, तो उन्हें 1, 2, ..., n, आदि के साथ प्रत्यय देना चाहिए।

उपसर्ग सारणी / स्तंभ: यह एक बड़ा विषय है, बाद में चर्चा करेंगे।

आवरण: यह ऊंट का मामला होना चाहिए

मेरे मित्र, पैट्रिक करचर , मैं आपसे अनुरोध करता हूं कि कृपया ऐसा कुछ न लिखें, जो किसी के लिए अपमानजनक हो, जैसा कि आपने लिखा है, "• आगे, विदेशी चाबियों को लगातार अलग-अलग तालिकाओं में नामित किया जाना चाहिए। किसी ऐसे व्यक्ति के साथ मारपीट करना कानूनी होना चाहिए जो ऐसा नहीं करता है। यह करो।"। मैंने अपने दोस्त पैट्रिक से यह गलती कभी नहीं की है, लेकिन मैं आम तौर पर लिख रहा हूं। क्या होगा अगर वे मिलकर इसके लिए आपको पीटने की योजना बनाते हैं? :)

Comments

तो आप कह रहे हैं कि तालिका इकाई है? या तालिका इकाई में पंक्ति है? मेरे लिए एक तालिका पंक्तियों का एक संग्रह है - इसलिए उन संस्थाओं का एक संग्रह है जो बहुवचन का अर्थ है।

— जेसन

Answer 20

पार्टी के लिए बहुत देर हो चुकी है लेकिन मैं अभी भी कॉलम उपसर्गों के बारे में अपने दो सेंट जोड़ना चाहता था

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

1) आपको अपने प्रश्नों में तालिका के नाम और / या स्तंभ उपनाम निर्दिष्ट करने की आवश्यकता नहीं है

2) आप कॉलम नाम के लिए अपना पूरा कोड आसानी से खोज सकते हैं

मुझे लगता है कि दोनों तर्क त्रुटिपूर्ण हैं। उपसर्गों का उपयोग किए बिना दोनों समस्याओं का समाधान आसान है। यहाँ मेरा प्रस्ताव है:

हमेशा अपने SQL में टेबल नाम का उपयोग करें। जैसे, कॉलम के बजाय हमेशा टेबल का उपयोग करें।

यह स्पष्ट रूप से 2) हल करता है क्योंकि आप अब table_column की जगह table.column की खोज कर सकते हैं।

लेकिन मैं आपको चिल्लाते हुए सुन सकता हूं, यह 1 कैसे हल करता है)? इससे बचना ही ठीक था। हाँ, यह था, लेकिन समाधान बुरी तरह से दोषपूर्ण था। क्यों? ठीक है, उपसर्ग समाधान नीचे उबलता है:
तालिका निर्दिष्ट करने से बचने के लिए जब अस्पष्टता होती है, तो आप अपने सभी स्तंभों का नाम table_column!
लेकिन इसका मतलब है कि अब से आप हमेशा एक कॉलम निर्दिष्ट करते समय हर बार कॉलम नाम लिखना होगा। लेकिन अगर आपको ऐसा करना है, तो हमेशा स्पष्ट रूप से तालिका लिखने में क्या लाभ है। कॉलम? वास्तव में, कोई लाभ नहीं है, यह ठीक उसी प्रकार के वर्णों की संख्या है।

संपादित करें: हाँ, मुझे पता है कि उपसर्ग के साथ कॉलम का नामकरण सही उपयोग को लागू करता है जबकि मेरा दृष्टिकोण प्रोग्रामर पर निर्भर करता है

Comments

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

— dallin

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

— अल्पावि

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

— dallin

Answer 21

आवश्यक डेटाबेस नामकरण कन्वेंशन (और स्टाइल) (अधिक विस्तृत विवरण के लिए यहां क्लिक करें)

तालिका के नाम छोटे, असंदिग्ध नामों का चयन करते हैं, एक या दो शब्दों से अधिक का उपयोग नहीं करते हैं तालिकाएँ आसानी से अद्वितीय फ़ील्ड नामों के नामकरण की सुविधा प्रदान करती हैं और तालिकाओं को जोड़ने और तालिकाओं को जोड़ने के लिए तालिकाओं का नाम देते हैं, कभी भी बहुवचन नहीं देते हैं (अपडेट: मैं अभी भी दिए गए कारणों से सहमत हूं इस सम्मेलन के लिए, लेकिन ज्यादातर लोग वास्तव में बहुवचन तालिका के नाम पसंद करते हैं, इसलिए मैंने अपना रुख नरम कर लिया है) ... कृपया ऊपर दिए गए लिंक का पालन करें

Comments

यद्यपि ओरेकल ऊपर लिंक को जोड़ने के लिए इसके विपरीत क्या सुझाव देता है। ओरेकल यहां क्या कहता है .. ss64.com/ora/syntax-naming.html

— AZ_

यह जवाब लगभग 3 साल पहले ही दिया जा चुका है ...

— fretje

ओरेकल का नामकरण सम्मेलन उन सभी में सबसे मजेदार था .. e.g. PATIENTS would have a primary key called pa_patient_id_pk!!

— नवफाल

Answer 22

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

Answer 23

--Example SQL

CREATE TABLE D001_Students
(
    StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
    ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
    Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);

CREATE INDEX idxD001_STID on D001_Students;

CREATE TABLE D002_Classes
(
    ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
    StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
    ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
    CONSTRAINT fkD001_STID FOREIGN KEY(StudentID) 
        REFERENCES D001_Students(StudentID)
);

CREATE INDEX idxD002_CLID on D002_Classes;

CREATE VIEW V001_StudentClasses
(
    SELECT
        D001.ChristianName,
        D001.Surname,
        D002.ClassName
    FROM
        D001_Students D001
            INNER JOIN
        D002_Classes D002
            ON
        D001.StudentID = D002.StudentID
);

ये वे सम्मेलन हैं जो मुझे सिखाए गए थे, लेकिन आपको जो भी विकास नली का उपयोग करना चाहिए, उसके अनुकूल होना चाहिए।

1. बहुवचन। यह संस्थाओं का एक संग्रह है।
2. हाँ। विशेषता एक इकाई की विलक्षण संपत्ति का प्रतिनिधित्व है।
3. हां, उपसर्ग तालिका नाम सभी बाधाओं और टेबल उपनामों के आसानी से ट्रैक करने योग्य नामकरण की अनुमति देता है।
4. तालिका और स्तंभ नामों के लिए पास्कल प्रकरण, उपसर्ग + सूचकांक और बाधाओं के लिए सभी कैप।

Comments

ChristianName ... यह एक अजीब सम्मेलन है।

— बॉबीशाफ्टे

आपके टेबल पर सीरियल नंबर? किसी को भी गंभीरता से लगता है कि यह समझ में आता है करता है काम करता है डेवलपर्स के लिए?

— एरिक

चूंकि यह उदाहरण सामने लाया गया ... मैं व्यक्तिगत रूप से तालिका या स्तंभ नामों में अपरकेसिंग के खिलाफ हूं, जैसा कि मुझे लगता है कि यह पढ़ने में मुश्किल बनाता है। इसलिए इस मामले में, मैं कहूंगा कि StudentId, StudentID के लिए बेहतर है। जब एंकाउट अंत में हो तो कोई बड़ी बात नहीं है, लेकिन मैंने अपनी नौकरी में अनगिनत उदाहरण देखे हैं जहाँ नाम के बीच या बीच में समोसे थे और इससे आपके दिमाग में पार्स करना मुश्किल हो गया। Ex: StudentABCSSN बनाम छात्रएबीसी।

— RedOctober13