तालिका नामकरण दुविधा: एकवचन बनाम बहुवचन नाम [बंद]

1466

शिक्षाविदों के पास यह है कि तालिका के नाम उस इकाई का एकवचन होना चाहिए जिसे वे विशेषताएँ संग्रहीत करते हैं।

मैं किसी भी टी-एसक्यूएल को नापसंद करता हूं, जिसमें नामों के चारों ओर चौकोर कोष्ठक की आवश्यकता होती है, लेकिन मैंने एक Usersतालिका का नाम बदलकर एकवचन रखा है, हमेशा के लिए तालिका का उपयोग करने वालों को कभी-कभी कोष्ठक का उपयोग करना होता है।

मेरी आंत महसूस करती है कि एकवचन के साथ रहना अधिक सही है, लेकिन मेरी आंत का अनुभव यह भी है कि कोष्ठक अवांछनीयता को इंगित करते हैं जैसे स्तंभ नाम उनके साथ रिक्त स्थान आदि।

में रूकू या जाऊं?

sql  sql-server  naming-conventions 
— प्रो.के.
स्रोत
पहले वाले डेटाबेस टेबलों का नामकरण, बहुवचन या एकवचन , लेकिन इस पर अधिक ध्यान गया।
— 1
7
मुझे आश्चर्य है कि अधिक लोग यह नहीं कह रहे हैं: यह इस बात से निर्धारित होता है कि एकल पंक्ति क्या दर्शाती है। किसी एकल डेटाबेस में मेरे पास एक तालिका हो सकती है, जिसकी पंक्तियाँ एकल विजेट का प्रतिनिधित्व करती हैं, और दूसरा उस तालिका के लिए एक से कई संबंधों का अर्थ है कि पंक्तियाँ कई विजेट का प्रतिनिधित्व करती हैं। ऐसा नहीं करने से स्पष्टता घटती है।
— andygavin
1
मैं बस इतना चाहता हूं कि इन सभी चर्चाओं में, कृपया ध्यान दें कि किसी भी तरह से एक तालिका आकार या एक वर्ग के रूप में नहीं बनाती है। एक तालिका एक विशिष्ट प्रकार के तत्वों का एक संग्रह है जिसे व्यक्तिगत गुणों पर सॉर्ट किया जा सकता है, बुझाया जा सकता है, आदि। एक वर्ग एक विशिष्ट प्रकार के गुणों और व्यवहार का वर्णन करने के लिए रूपरेखा है। OO कोडिंग के संदर्भ में, तालिका में प्रतिनिधित्व को बंद करना वस्तुओं का एक संग्रह है। (कोई फर्क नहीं पड़ता कि आप किस ORM का उपयोग कर रहे हैं)। यह इस विषय पर अब तक का सर्वोच्च रैंकिंग वाला Google उत्तर है, इसलिए हालांकि यह प्रश्न बंद है, फिर भी पृष्ठ का मूल्य है।
1
मैं उस पारिस्थितिक तंत्र के सामान्य अभ्यास के लिए जाऊंगा जिसमें आप काम कर रहे हैं। उदाहरण के लिए: बुकशेल्फ़.जेएस या ऑब्जेक्शन जैसे Node.js ORM में। मुख्य रूप से "Knex.js" पर आधारित हैं। और "Knex.js" प्रलेखन में आपको बहुवचन में तालिका के नाम मिलेंगे। इसलिए मैं उस डोमेन में बहुवचन के लिए जाऊंगा। स्रोत: knexjs.org/#Schema-createTable
— बेनी
2
हाँ मैं सहमत हूँ। यह समझ में आता है कि उपयोगकर्ताओं की एक तालिका है और इसे "AppUser" कहते हैं, साथ ही यह एक विशेष प्रकार के उपयोगकर्ता के लिए लागू नियमों की एक तालिका है और इसे "UserRules" कहते हैं
— Arindam

जवाबों:

243

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

— टॉम एच
स्रोत
7
मैं सहमत हूँ। किसी कीवर्ड का उपयोग करने से बचने के लिए ऑर्गुयर्स, ऐपयूजर, कुछ भी।
— माइक डब्ल्यू
7
-1। तालिका उपयोगकर्ता (और देश, भाषा) कुछ अनुप्रयोगों में एक साथ उपयोग किए जा सकते हैं।
— OZ_
129
स्कीमा नाम को जोड़ना सभी भ्रम को दूर नहीं करेगा? AppName1.Users, AppName2.Users?
— Zo ने
7
मैं तालिका उपसर्ग से असहमत हूं - कि शायद एक स्कीमा होना चाहिए? - लेकिन मैं "अधिक वर्णनात्मक नाम" से सहमत हूं। यहां तक ​​कि "अप्पुसर" के रूप में सरल कुछ भी पर्याप्त होगा, पूरे नामस्थान बहस में प्रवेश किए बिना।
7
यह स्वीकृत उत्तर साइड-कमेंट का अधिक है और प्रश्न का उत्तर नहीं देता है।
— वलियामी
1822

मेरे पास एक ही सवाल था, और यहाँ सभी उत्तरों को पढ़ने के बाद मैं निश्चित रूप से सिंघलार के साथ रहा, कारण:

कारण 1 (अवधारणा)। आप "AppleBag" जैसे सेब युक्त बैग के बारे में सोच सकते हैं, इससे कोई फर्क नहीं पड़ता कि इसमें 0, 1 या एक लाख सेब हों, यह हमेशा एक ही बैग होता है। टेबल्स सिर्फ इतना है कि, कंटेनरों, तालिका के नाम का वर्णन करना चाहिए कि इसमें क्या है, न कि इसमें कितना डेटा है। इसके अतिरिक्त, बहुवचन अवधारणा एक बोली जाने वाली भाषा के बारे में अधिक है (वास्तव में यह निर्धारित करने के लिए कि क्या एक या अधिक है)।

कारण 2 । (सुविधा)। यह बहुवचन नाम के साथ बहुवचन के साथ आसान है। वस्तुओं में अनियमित बहुवचन हो सकते हैं या बहुवचन नहीं हो सकते हैं, लेकिन हमेशा एक विलक्षण एक (समाचार जैसे कुछ अपवादों के साथ) होगा।

  • ग्राहक
  • गण
  • उपयोगकर्ता
  • स्थिति
  • समाचार

कारण 3 । (एस्थेटिक एंड ऑर्डर)। विशेष रूप से मास्टर-डिटेल परिदृश्यों में, यह बेहतर पढ़ता है, नाम से बेहतर संरेखित करता है, और अधिक तार्किक क्रम होता है (मास्टर पहले, विस्तार दूसरे):

  • 1.Order
  • 2.OrderDetail

की तुलना में:

  • 1.OrderDetails
  • 2.Orders

कारण 4 (सादगी)। सभी को एक साथ रखें, तालिका नाम, प्राथमिक कुंजी, संबंध, इकाई वर्ग ... दो (एकवचन वर्ग, बहुवचन तालिका, एकवचन क्षेत्र, एकवचन-बहुवचन-विस्तार) के बजाय केवल एक नाम (एकवचन) के बारे में पता होना बेहतर है। ।)

  • Customer
  • Customer.CustomerID
  • CustomerAddress
  • public Class Customer {...}
  • SELECT FROM Customer WHERE CustomerID = 100

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

कारण ५ । (वैश्वीकरण)। दुनिया छोटी हो रही है, आपके पास अलग-अलग राष्ट्रीयताओं की एक टीम हो सकती है, हर किसी के पास मूल भाषा के रूप में अंग्रेजी नहीं है। गैर-देशी अंग्रेजी भाषा प्रोग्रामर के लिए "रेपोज़िटरीज़" या "स्टेटस" के बजाय "स्टेटस" के बजाय "रिपॉजिटरी" के बारे में सोचना आसान होगा। एकल नाम होने से टाइपोस के कारण होने वाली कम त्रुटियां हो सकती हैं, यह सोचने में समय न बचाएं कि "क्या यह बाल या बच्चे हैं?", इसलिए उत्पादकता में सुधार होगा।

कारण 6 । (क्यों नहीं?)। यह आपको लिखने का समय भी बचा सकता है, आपको डिस्क स्थान बचा सकता है, और यहां तक ​​कि आपके कंप्यूटर कीबोर्ड को भी लंबे समय तक बना सकता है!

  • SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100
  • SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 100

आपने 3 अक्षर, 3 बाइट, 3 अतिरिक्त कीबोर्ड हिट सहेजे हैं :)

और अंत में, आप उन लोगों को नाम दे सकते हैं जो आरक्षित नामों के साथ गड़बड़ कर रहे हैं:

  • उपयोगकर्ता> LoginUser, AppUser, SystemUser, CMSUser, ...

या बदनाम वर्ग कोष्ठक का उपयोग करें [उपयोगकर्ता]

— नेस्टर
स्रोत
622
यदि आप एक नकली दराज पर एक लेबल लगाते हैं तो मैं शर्त लगाता हूँ कि आप इसे "Socks" कहेंगे।
— क्रिस वार्ड
73
Definetelly। एक मानक प्राप्त करना मुश्किल है जो सभी के लिए और सभी के लिए काम करता है, महत्वपूर्ण यह है कि आपके लिए काम करता है। यह मेरे लिए काम करता है, और यहां मैंने बताया है कि क्यों, लेकिन फिर से, यह मेरे लिए है, और मुझे यह बहुत सुविधाजनक लगता है।
— नेस्टर
451
बड़ा सवाल क्रिस, एक जुर्राब दराज का नामकरण करते हुए आप डेटाबेस के नामकरण सम्मेलनों का पालन क्यों करेंगे?
— काइल क्लेग
83
इस उत्तर को अधिक प्रशंसा की आवश्यकता है। यह व्यावहारिक कारणों की एक गुच्छा पर चर्चा करता है जो मैं लागू करता हूं कि मैं एकवचन नामों को क्यों पसंद करता हूं। समुच्चय के संदर्भ में उचित भाषा के बारे में वैकल्पिक चर्चाएं केवल दार्शनिक हैं और वास्तविक बिंदु को अस्पष्ट कर रही हैं। विलक्षण सिर्फ बेहतर काम करता है।
— जेसन
298
मेरे पास घर पर "सॉक" दराज है, न कि "सॉक्स" दराज। यदि यह एक डेटाबेस होता, तो मैं इसे "सॉक" टेबल कहता।
— jlembke
260

यदि आप ऑब्जेक्ट रिलेशनल मैपिंग टूल का उपयोग करते हैं या भविष्य में मैं सिंगुलर का सुझाव दूंगा ।

LLBLGen जैसे कुछ उपकरण स्वतः ही बहुवचन नाम को सही कर सकते हैं जैसे उपयोगकर्ता को उपयोगकर्ता के लिए तालिका का नाम बदले बिना। यह बात क्यों है? क्योंकि जब इसे मैप किया जाता है तो आप चाहते हैं कि यह User.Name के बजाय उपयोगकर्ता के समान दिखे। नाम या मेरे पुराने डेटाबेस तालिकाओं में से कुछ से भी बदतर tblUsers.strName जो कोड में भ्रमित कर रहा है।

मेरे अंगूठे का नया नियम यह निर्धारित करना है कि एक वस्तु में परिवर्तित होने के बाद यह कैसा दिखेगा।

एक तालिका जो मैंने पाया है कि मेरे द्वारा उपयोग किए जाने वाले नए नामकरण के लिए उपयुक्त नहीं है। लेकिन वहाँ हमेशा उन कुछ अपवाद होंगे और इस मामले में भी यह UsersInRoles.Username के रूप में ठीक लगता है।

— ब्रायन बोटराइट
स्रोत
48
मैंने मतदान किया और मैं आपको बताऊंगा कि क्यों, क्योंकि मैं असहमत हूं। ORM द्वारा यह बहुत प्रकृति मानचित्रण के बारे में है। हर ORM उपकरण जो मैंने कभी इस्तेमाल किया है, वह एक इकाई के लिए उपयोग किए जाने वाले तालिका नाम को निर्दिष्ट करने का समर्थन करता है जब यह इकाई के नाम से अलग होता है। यह महत्वपूर्ण है क्योंकि संपूर्ण कारण जो हम संबंधपरक डेटाबेस के लिए मैप करते हैं ताकि हम आसानी से अपने ऑब्जेक्ट मॉडल की तुलना में अलग-अलग आकृतियों के साथ तदर्थ क्वेरी और रिपोर्ट बना सकें। अन्यथा हम सभी अभी तक ऑब्जेक्ट / दस्तावेज़ डेटाबेस का उपयोग कर रहे हैं।
— joshperry
25
ओआरएम को उन वस्तुओं के नामों को निर्देशित नहीं करना चाहिए जिनके लिए वे मैप करते हैं। ORM का बिंदु वस्तु का एक अमूर्त हिस्सा है, जो इस फ्लेक्सिबिलिटी को प्रदान करता है।
— बैरीपिकर
19
मेरी दुनिया में मैं इस बात को समझने में समय बर्बाद करने से बचने के लिए पूरे प्रोजेक्ट में लगातार नामों का उपयोग करने की कोशिश करता हूं कि क्या यह उदाहरण अंत में है या नहीं। तथ्य यह है कि एक ORM कर सकते हैं का नाम बदलने और स्वतंत्र नहीं करता हो मतलब है कि ऐसा करने से आपके साथी डेवलपर मदद कर रहा है।
— जॉन निकोलस
2
कुछ ORM (जैसे कई प्रोग्रामिंग टूल) में डिफ़ॉल्ट व्यवहार होता है जो कॉन्फ़िगरेशन के बिना कार्यान्वयन को उत्पन्न करता है ... उत्पादकता के विक्रय बिंदु के साथ। तो स्पष्ट रूप से मैपिंग के बिना एक कर्मचारी वर्ग का निर्माण, डिफ़ॉल्ट रूप से एक कर्मचारी तालिका उत्पन्न करेगा
— user919426
1
@barrypicker। बहुवचन नाम केवल ORM कोड में गूंगा नहीं दिखता है। एसक्यूएल में भी प्लुरल खराब दिखते हैं, खासकर जब एक अनूठी विशेषता का जिक्र होता है। किसने कभी नहीं लिखा है चुनिंदा user.id उपयोगकर्ताओं से? या शायद ... बचे हुए उपयोगकर्ताओं से thingy.user_id = user.id पर शामिल हों ...?
— सैमुअल डेनियलसन
219

मैं बिन बुलाए संज्ञा का उपयोग करना पसंद करता हूं , जो अंग्रेजी में विलक्षण होता है।

तालिका के नाम की संख्या को दर्शाने से ऑर्थोग्राफ़िक समस्याएं होती हैं (जैसा कि अन्य उत्तरों में से कई दिखाते हैं), लेकिन ऐसा करने के लिए चुनना क्योंकि टेबल में आमतौर पर कई पंक्तियाँ होती हैं वे भी शब्दार्थ से भरी होती हैं। यह अधिक स्पष्ट है अगर हम ऐसी भाषा पर विचार करें जो संज्ञा को मामले के आधार पर विभक्त करती है (जैसा कि अधिकांश करते हैं):

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

असंक्रमित संज्ञा का प्रयोग सरल, तार्किक, नियमित और भाषा-स्वतंत्र है।

— इयान मैकिनन
स्रोत
37
संभवतः इस विषय पर सबसे तार्किक तर्क मैंने कभी देखा है, और मुझे खुशी है कि मैंने उस समय को लैटिन में बिताया है। निश्चित के लिए +1।
52
वैसे मुझे स्पष्ट रूप से अपनी शब्दावली को गोमांस करने की आवश्यकता है।
— टीजे बिडल
19
+1 देखें, ये उन उत्तरों के प्रकार हैं जिनकी इंटरनेट को अधिक आवश्यकता है। अचूक तर्क का उपयोग करने के लिए समृद्ध शब्दावली का उपयोग करने योग्य सबूत।
— OCDev
8
मैं अगली बार लैटिन में प्रोग्रामिंग कर रहा हूँ, इस पर ध्यान दूंगा। इस बीच में उपयोगकर्ता उपयोगकर्ताओं की तालिका में और ग्राहक ग्राहकों की तालिका में जाएंगे।
— कलस्टर
8
अभिप्रेरित - असंख्यात यह है। यह देखना दिलचस्प है कि इस समय के बाद, "विलक्षण" और "बहुवचन" के लोकप्रिय विकल्प दोनों गलत हैं!
— स्टुअर्ट
126

क्या सम्मेलन की आवश्यकता है कि तालिकाओं में एकवचन नाम हैं? मुझे हमेशा लगा कि यह बहुवचन नाम है।

उपयोगकर्ता तालिका में एक उपयोगकर्ता जोड़ा जाता है।

यह साइट सहमत है:
http://vyaskn.tripod.com/object_naming.htm#Tables

यह साइट असहमत है (लेकिन मैं इससे असहमत हूं):
http://justinsomnia.org/writings/naming_nvent.html

जैसा कि दूसरों ने उल्लेख किया है: ये सिर्फ दिशा-निर्देश हैं। एक सम्मेलन चुनें जो आपके और आपकी कंपनी / परियोजना के लिए काम करता है और इसके साथ रहना है। एकवचन और बहुवचन के बीच स्विच करना या कभी-कभी शब्दों को संक्षिप्त करना और कभी-कभी अधिक उत्तेजित नहीं करना।

— माइकल हरेन को दर्शाता है
स्रोत
46
तालिकाओं पर सेट सिद्धांत लागू करते समय, सेट में कोई भी उदाहरण सेट का प्रतिनिधि होता है, इसलिए Apple एक Apple सेट है, यह अज्ञेय है कि सेट में कितने सेब हैं - यह एक Apple है जिसमें कई उदाहरण हैं। सेब का एक 'बैग' तब नहीं बनता है जब उसमें कई सेब होते हैं।
— प्रोफेक डे
89
यदि आपके पास 5 सेब के साथ एक बैग है तो क्या होगा? क्या आप इसे सेब का थैला कहते हैं? या सेब का एक बैग?
— क्रिस्टोफर महान
26
मुझे लगता है कि सिद्धांत यह होगा कि सेट का नाम सेब है। एक विलक्षण सेब अभी भी "सेब का एक सेट" है - यद्यपि, एक एकल उदाहरण के साथ एक सेट। एकाधिक सेब एक "सेब का सेट" भी हैं।
— मार्क ब्रैकेट
26
@ क्रिस्‍टोफर, यदि बैग का राइसन डी'आट्रे सेब और केवल सेब रखने के लिए है, तो यह "सेब बैग" है, भले ही इसमें 1 सेब, 100 सेब या कोई सेब न हो।
— इयान मैकिनॉन
14
@ इयान: ऐसा इसलिए है क्योंकि एक टेबल जेनेरिक है, और इसकी तुलना शिपिंग कंटेनर से की जा सकती है (इसमें लगभग कुछ भी हो सकता है, जिसमें सेब क्रेट से लेकर हार्ले डेविडसन मोटरसाइकिल के क्रेट तक)। आप कहते हैं: संतरे का कार्गो कंटेनर, नारंगी कार्गो कंटेनर नहीं। आप कहते हैं: कार भागों का कार्गो कंटेनर, कार भागों कार्गो कंटेनर नहीं। यदि आपने एक कस्टम डेटा संरचना बनाई है, जिसका अर्थ केवल विशिष्ट प्रकार के डेटा को रखना है, जैसे कि सेब के नाम, और आपने इसे "कुंगबोगो" नाम दिया है, तो आपके पास एक सेब कुंगबोको हो सकता है। मुझे पता है कि आपकी सोच क्या है, लेकिन पहले गेंदों की एक थैली के बारे में सोचें, और अर्थ में अंतर को समझें।
— क्रिस्टोफर महान
79

कैसे एक साधारण उदाहरण के रूप में इस बारे में:

SELECT Customer.Name, Customer.Address FROM Customer WHERE Customer.Name > "def"

बनाम

SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"

उत्तरार्द्ध में SQL पूर्व की तुलना में अजनबी लग रहा है।

मैं एकवचन को वोट देता हूं ।

— जेम्स
स्रोत
49
उस उदाहरण में, हां, लेकिन व्यावहारिक एसक्यूएल में ऐसा कभी नहीं लिखा जाएगा। आपके पास एक टेबल उपनाम है, इसलिए यह अधिक पसंद होगाSELECT C.Name, C.Address FROM Customers WHERE Customers.Name > 'def'
— माइकल हरेन
+1, (एक वर्ष बाद) आपने एक उदाहरण का उल्लेख किया कि कैसे एकवचन समझ में आता है। यह कुछ हद तक एक धार्मिक बहस है। मैं कई साल पहले एक डेटा वास्तुकार द्वारा कई साल पहले मेरे वरिष्ठ पर बदल गया था और यह मुझे सही लगा (बाद में मुझे स्विच करने के लिए बहुत समझाने की आवश्यकता थी)।
— क्रिस एड्रैगन
24
मुझे लगता है कि sql बेहतर बहुवचन लगता है। आपके पास प्रत्येक कॉलम के लिए टेबल के नाम नहीं होंगे, आपको टाइपिंग इतना पसंद क्यों है। सेलेक्ट नाम, पता फ्रॉम कस्टमर्स व्हेयर नेम> "डीएफ़" आप उन ग्राहकों के पूल से चयन कर रहे हैं जहाँ नाम अधिक बड़ा है।
— जैमिग्स
6
कैसे एक उपनाम / एएस का उपयोग करने के बारे में उस एक मुद्दे के आसपास? ग्राहक का चयन करें। नाम, ग्राहक। ग्राहक से ग्राहक के रूप में जहां ग्राहक हो। नाम> "डीईएफ़"
— जेम्स ह्यूजेस
1
दूसरा एक बहुत अच्छा लगता है, एकवचन लगता है जैसे कोई अंग्रेजी नहीं बोल सकता।
— HLGEM
61

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

यह तब SQL कथन में अधिक मायने रखता है क्योंकि आप रिकॉर्ड के एक समूह से चयन कर रहे हैं और यदि तालिका का नाम एकवचन है, तो यह अच्छी तरह से पढ़ा नहीं जाता है।

— एडम कैर को दर्शाता है
स्रोत
3
मैं विशेष रूप से SQL कथन टिप्पणी पसंद करता हूं। यहाँ एकवचन का प्रयोग पाठक को सहज नहीं लगता।
— hochl
2
ईआरडी के बारे में उत्कृष्ट बिंदु। मुझे संदेह है कि ऐसा क्यों है, जो डीबीए आंखों के माध्यम से दुनिया को देखता है, एकवचन नामकरण समझ में आता है। मुझे संदेह है कि वे नहीं मिलते हैं, जैसा कि आप बताते हैं, एक इकाई और उनमें से एक संग्रह के बीच का अंतर।
— विलियम टी। मल्लार्ड
1
एक तालिका अभिलेखों का संग्रह नहीं है; तालिका एक परिभाषा है जो रिकॉर्ड की तरह दिखता है। यह सभी बहुवचन / एकवचन लोक प्रतीत होता है।
— अमीर रीम
मैं एसक्यूएल बयान टिप्पणी से असहमत हूं। क्या आप Users.Id के खिलाफ शामिल करना चाहते हैं, तो
— hashtable
1
एक old_lady के पास कई cat हैं या old_ladies के पास बिल्लियाँ हैं। मुझे लगता है कि ERDs ने बहुवचन के रूप में अच्छे से पढ़ा। और संस्थाओं की तालिका, तालिकाओं में कई संस्थाएं हैं इसलिए मुझे लगता है कि बहुवचन अच्छा लगता है।
— user3121518
39

मैं टेबल नामों और किसी भी प्रोग्रामिंग इकाई के लिए एकवचन के साथ रहता हूं ।

कारण? तथ्य यह है कि अंग्रेजी में माउस ⇒ चूहे और भेड़ ⇒ भेड़ की तरह अनियमित plurals हैं । फिर, अगर मुझे एक संग्रह की आवश्यकता है, तो मैं सिर्फ पति या पत्नी या भेड़ का बच्चा उपयोग करता हूं , और आगे बढ़ता हूं ।

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

तो, मेरा नियम है: सब कुछ विलक्षण है, चीजों का हर संग्रह एक एस के साथ एकवचन है। ओआरएम के साथ भी मदद करता है।

— पाउलो फ्रीटास
स्रोत
7
एक 'एस' के साथ समाप्त होने वाले शब्द के बारे में क्या? यदि आपके पास 'समाचार' (केवल एक उदाहरण के रूप में) नामक एक तालिका है, तो आप समाचारों के संग्रह को क्या कहेंगे? Newss? या आप टेबल को 'न्यू' कहेंगे?
— एंथनी
18
मैं टेबल NewsItem और एक संग्रह NewsItems कहूंगा।
— ऐश मशीन २
5
क्या होगा यदि आपको सभी कोड की वर्तनी जांचनी होगी, अन्यथा यह संकलन नहीं करेगा;)
— हमीश ग्रुबीजन
2
ओआरएम को उन वस्तुओं के नामों को निर्देशित नहीं करना चाहिए जिनके लिए वे मैप करते हैं। ORM का बिंदु वस्तु का एक अमूर्त हिस्सा है, जो इस फ्लेक्सिबिलिटी को प्रदान करता है।
— बैरीपिकर
16
@ HamishGrubijan फिर अपना कोड लिखने के लिए Word का उपयोग करना बंद करें! ;)
— वैलेंटिनो वॉनकेन
36

IMHO, तालिका नाम ग्राहकों की तरह बहुवचन होना चाहिए ।

यदि ग्राहक तालिका में एक पंक्ति में मैप करता है, तो क्लास नाम ग्राहक की तरह एकवचन होना चाहिए ।

— गुलज़ार नाज़िम
स्रोत
32

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

मेरा मुख्य तर्क यह है कि मैं तालिकाओं को एक सेट के रूप में नहीं बल्कि संबंधों के रूप में समझता हूं।

तो, AppUserसंबंध बताता है कि कौन सी संस्थाएं हैं AppUsers।

AppUserGroupसंबंध मुझसे कहता है जो संस्थाएं हैंAppUserGroups

AppUser_AppUserGroupसंबंध मुझे बताता है कि कैसे AppUsersऔर AppUserGroupsजुड़े हुए हैं।

AppUserGroup_AppUserGroupसंबंध मुझे बताता है कि कैसे AppUserGroupsऔर AppUserGroupsसे संबंधित हैं (समूहों में से यानी समूहों सदस्य)।

दूसरे शब्दों में, जब मैं संस्थाओं के बारे में सोचता हूं और वे कैसे संबंधित होते हैं तो मैं एकवचन में संबंधों के बारे में सोचता हूं, लेकिन निश्चित रूप से, जब मैं संग्रह या सेट में संस्थाओं के बारे में सोचता हूं, तो संग्रह या सेट बहुवचन होते हैं।

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

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

— जैकब लोरेंसन
स्रोत
1
बिल्कुल सही। मुख्य बात यह है कि बहुत से लोग जानते नहीं हैं कि वे क्या नाम दे रहे हैं ... आप एक रिश्ते को नाम दे रहे हैं (तालिका में एक एकल रिकॉर्ड), तालिका में रिकॉर्ड का सेट नहीं।
— एलेक्जेंड्रे मार्टिनी
3
अधिक असहमत नहीं किया जा सका। 'यूजर्स' से 'सेलेक्ट' जहां 'जे%' जैसे नाम हैं क्योंकि मैं उन सभी यूजर्स को चुन रहा हूं जहां नाम 'जे' से शुरू होता है। यदि आपका तर्क यह है कि आप '... जहाँ User.Name like ...' लिखना चाहते हैं, तो बस एक उपनाम का उपयोग करें। यही कारण है कि मैं कहता हूं 'मुझे सभी उपलब्ध मोजे से एक जोड़ी दें।'
— मार्क ए। डोनोहे
अगर मैं वह विशेष रूप से मेरा टेबल का नाम sock_pair होगा
— Manuel Hernandez
@AlexandreMartini बिल्कुल। कुछ लोगों की तरह, जो "संबंध" तालिका में एक एकल रिकॉर्ड कहते हैं।
— नूनो आंद्रे
31

मैं प्लुरल के साथ भी जाऊंगा , और उपर्युक्त उपयोगकर्ता दुविधा के साथ, हम स्क्वायर ब्रैकेटिंग दृष्टिकोण अपनाते हैं।

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

हमारी डेटा टीम और हमारे डेवलपर्स के पास एक ही वैचारिक भाषा बोलने (हालांकि हमेशा समान ऑब्जेक्ट नाम नहीं) होने से उनके बीच विचारों को व्यक्त करना आसान हो जाता है।

— पाउलो फ्रीटास
स्रोत
8
मैं सहमत हूँ .. क्यों कोड और भंडारण के बीच असंगति? मैं कोड में उपयोगकर्ता ऑब्जेक्ट्स "उपयोगकर्ता" का एक संग्रह कभी भी नाम नहीं दूंगा ... तो मैं एक तालिका क्यों कहूंगा? इसका कोई मतलब नही बनता। जब मैं इसके बारे में ऊपर दिए गए तर्कों को पढ़ता हूं, तो वे इकाई पर ध्यान केंद्रित कर रहे हैं, तालिका पर नहीं ... मेरे दिमाग में तालिका की तुलना में तालिका में व्हाट्स के बीच एक अंतर है।
— जेसन
आप तालिका के नाम के साथ कैसे व्यवहार करते हैं जैसे companiesअन्य तालिकाओं में एक संदर्भ क्षेत्र कहा जाता है company_id? जबकि यह ठीक से वर्तनी है, यह उन लोगों के लिए असंगत लगता है जो टेबल नामकरण सम्मेलनों के बारे में अचार हैं।
— जेक विल्सन
1
यह याद करके कि एकवचन companiesहै company, और यह आईडी एक विलक्षण वस्तु का संदर्भ है। यह हमें किसी भी कोड में परेशान नहीं करना चाहिए, क्योंकि यह हमें अंग्रेजी में परेशान करता है।
— डेविड
22

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

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

इस सूत्र में सभी तर्क पढ़ने के बाद, मैं एक निष्कर्ष पर पहुंचा:

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

— कोई व्यक्ति
स्रोत
रिलेशनल मॉडल की दुनिया में इस तरह के सम्मेलन का उपयोग करना बुद्धिमानी नहीं है, खासकर जब आप वस्तुओं के बीच संबंध का वर्णन करते हैं, उदाहरण के लिए "प्रत्येक टीम में केवल एक मुख्य कोच और कई माध्यमिक कोच हो सकते हैं", जिसका वर्णन किया गया है: टीम-> मेनकॉच, टीम - >> सेकेंडरीकॉच
— noonex
16

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

मैं हर समय ओआरएम का उपयोग करता हूं, और यह मदद करता है कि बहुवचन टेबल नामों के साथ लिखे गए ओआरएम कोड बेवकूफ लगते हैं।

— अराजकता
स्रोत
मेरा अंदाज़ा है कि हरेक को उसका अपना। एक रिलेशनल डेटाबेस टेबल परिभाषा के अनुसार एक हेडिंग है (यानी मेटाडेटा नामकरण विशेषताएँ) और शीर्षकों से मेल खाते टुपल्स का एक सेट। आप मेटाडेटा पर ध्यान केंद्रित कर सकते हैं, जबकि अन्य लोग ट्यूपल्स पर ध्यान केंद्रित करते हैं। :-)
— बिल कार्विन
अरे, User_Table एक ऐसा नाम है जो मुझे पसंद है! :)
— कैमिलो मार्टिन
3
ओआरएम को उन वस्तुओं के नामों को निर्देशित नहीं करना चाहिए जिनके लिए वे मैप करते हैं। ORM का बिंदु वस्तु का एक अमूर्त हिस्सा है, जो इस फ्लेक्सिबिलिटी को प्रदान करता है।
— बैरीपिकर
1
मैं इसे इस तरह से देखता हूं .. यदि आप कोड में किसी भी चीज की एक सरणी / सूची / शब्दकोश बनाते हैं, तो मेरी शर्त है कि आप इसे जो भी मानते हैं उसका बहुवचन नाम के साथ नाम दें। यदि आप अपने डेटाबेस को सार करने के लिए एक ORM का उपयोग कर रहे हैं, तो तालिकाओं को किसी प्रकार के संग्रह के साथ दर्शाया जाता है, तो आप उन्हें किसी अन्य के साथ क्यों व्यवहार करेंगे? एकवचन नामों का उपयोग करने के लिए अच्छा लग सकता है, लेकिन आप हमेशा अपनी वृत्ति से लड़ रहे हैं कि एक टेबल एक ही चीज़ रखती है, जैसे कोड में एक संग्रह होता है। असंगति क्यों?
— जेसन
@Jason: कृपया तुलना और जिस तरह से इन बातों को पढ़ने के विपरीत: 1) $db->user->row(27), $db->product->rows->where(something) 2) $db->users->row(27), $db->products->rows->where(something)।
— अराजकता
16

मैंने वास्तव में हमेशा सोचा है कि बहुवचन तालिका नामों का उपयोग करने के लिए यह लोकप्रिय सम्मेलन था। इस बिंदु तक मैंने हमेशा बहुवचन का उपयोग किया है।

मैं एकवचन तालिका नामों के तर्क को समझ सकता हूं, लेकिन मेरे लिए बहुवचन अधिक मायने रखता है। एक तालिका नाम आमतौर पर वर्णन करता है कि तालिका में क्या है। एक सामान्यीकृत डेटाबेस में, प्रत्येक तालिका में डेटा के विशिष्ट सेट होते हैं। प्रत्येक पंक्ति एक इकाई है और तालिका में कई संस्थाएँ हैं। इस प्रकार तालिका नाम के लिए बहुवचन रूप।

कारों का एक तालिका नाम होता कारों और प्रत्येक पंक्ति एक कार है। मैं मानता हूँ कि क्षेत्र के साथ तालिका को एक table.fieldतरीके से निर्दिष्ट करना सबसे अच्छा अभ्यास है और यह कि विलक्षण तालिका के नाम अधिक पठनीय हैं। हालांकि निम्नलिखित दो उदाहरणों में, पूर्व अधिक समझ में आता है:

SELECT * FROM cars WHERE color='blue'
SELECT * FROM car WHERE color='blue'

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

— रैंडी
स्रोत
9
क्या यह RoR में सम्मेलन नहीं है? ओआरएम वर्गों के लिए तालिकाओं और एकवचन के लिए बहुवचन नाम? मेरे लिए बहुत मायने रखता है। टेबल को "कार" कहा जाता है क्योंकि इसमें "कार" के कई उदाहरण हैं और क्लास को "कार" कहा जाता है क्योंकि यह एक कार का एक उदाहरण रखेगी !!
— सैप
@ अपने वाक्य के उत्तरार्ध का एक मामूली सुधार - कक्षा "कार" एक वास्तविक जीवन कार का प्रतिनिधित्व करने वाला एक सार डेटाटेप है। चाहे वह एक उदाहरण को धारण करेगा या गुणक इस बात पर निर्भर करेगा कि इसका उपयोग कैसे किया जाता है
— asgs
इसका सामना करना पड़ता है, तालिका carएकल कार की संरचना की एक परिभाषा है। यदि आप तालिका की संरचना को देखते हैं, तो यह मूल रूप से "आईडी इंट, रंग स्ट्रिंग आदि" को बाहर थूक देगा: कहते हैं कि आपके पास विदेशी कुंजी के साथ एक मेज है car_vendor(या आपके बहुवचन संस्करण के लिए यह होगा cars_vendor) cars_id? वह मूर्ख बकवास क्या है? यह है car_id मुझे लगता है कि बनाने के लिए कोई जरूरत नहीं। मेरे द्वारा सिंगुलर को बहुत पसंद किया जाता है
— तोस्कान
4
मुझे वास्तव में यह उत्तर पसंद है! मुझे समझाने दो। संग्रह है carऔर आप से सब कुछ चाहते carहै कि blueपरिणाम की तरह कुछ किया जाना चाहिए tire, mirror, engine। और फिर यह भ्रमित हो रहा है क्योंकि सभी परिणाम partsएक से हैं car। इसलिए टेबल का नाम carparts(या car_parts, CarPartsजो भी आपको पसंद हो)
— arnoudhgz
कोई भी डेटाबेस डिज़ाइनर जो एकवचन तालिका नामों को लागू करता है, वह मूल रूप से किसी भी रूबी के खिलाफ Rails ऐप डेवलपर्स के खिलाफ युद्ध की घोषणा कर रहा है, जो भविष्य में उस डेटाबेस के संपर्क में आ सकता है। कक्षाओं के लिए एकवचन शब्दों पर रेल के सख्त आग्रह, और तालिकाओं के लिए बहुवचन नाम, रूबी के पारिस्थितिकी तंत्र के अंदर कई रत्नों के भीतर बहुत शक्तिशाली व्यवहार को सक्षम बनाता है। तो भी अगर आपको लगता है कि एकवचन बेहतर लगता है, तो अनुकूलता के लिए आपको बहुवचन से चिपके रहना चाहिए। मुझे लगता है कि यह कई अन्य ऑब्जेक्ट रिलेशनल मैपर के लिए भी सही है।
— केल्सी हन्नान
15

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

विडंबना यह है कि मैं कर सकता है Userएक अपवाद है और यह फोन Usersकी वजह से उपयोगकर्ता (Transac-एसक्यूएल) , क्योंकि मैं भी टेबल के आसपास कोष्ठक का उपयोग करता है, तो मैं की जरूरत नहीं है की तरह नहीं है।

मैं भी तरह सभी आईडी स्तंभ के रूप में नाम के लिए Idहै, न कि ChickenIdया ChickensId(क्या बहुवचन लोग इस बारे में क्या कर सकते हैं?)।

यह सब इसलिए है क्योंकि मेरे पास डेटाबेस सिस्टम के लिए उचित सम्मान नहीं है, मैं सिर्फ जावा के आदत और आलस्य जैसे ओओ नामकरण सम्मेलनों से एक-चाल-टट्टू ज्ञान को फिर से लागू कर रहा हूं । काश जटिल एसक्यूएल के लिए बेहतर आईडीई समर्थन थे।

— यूजीन योकोटा
स्रोत
8
हमारे बहुवचन लोग या तो 'आईडी' कॉलम 'आईडी' का नाम देते हैं, जैसे आप करते हैं, या 'एकवचन_'। मेरा मानना ​​है कि तालिकाओं को बहुवचन होना चाहिए (उन्हें सरणियों की तरह सोचना), लेकिन स्तंभ नाम एकवचन (एक तत्व के गुण) होना चाहिए।
— म्पेन
तालिका के नाम के लिए plu_ral / PluRal, प्राथमिक कुंजियों के लिए singular_id / singularId।
— hochl
14

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

SELECT [Name] FROM [dbo].[Customer] WHERE [Location] = 'WA'

इसने हमारी आत्माओं को अतीत में बचाया है - हमारे कुछ डेटाबेस सिस्टमों ने SQL 2005 के माध्यम से SQL 6.0 से 10+ वर्ष चलाए हैं - जिस तरह से उनके इच्छित जीवन काल के दौरान।

— stephbu
स्रोत
कर्मकांडी आत्म-ध्वज की तरह लगता है। क्या अभी तक ऐसा कोई नाम पकड़ में आया है?
— केजेटिल एस।
13

टेबल्स: बहुवचन

एकाधिक उपयोगकर्ताओं को उपयोगकर्ता तालिका में सूचीबद्ध किया गया है।

मॉडल: एकवचन

एक विलक्षण उपयोगकर्ता को उपयोगकर्ता तालिका से चुना जा सकता है।

नियंत्रक: बहुवचन

http://myapp.com/users कई उपयोगकर्ताओं को सूचीबद्ध करेगा।

वैसे भी उस पर मेरा कब्जा है।

— एंड्रयू
स्रोत
1
मेरे लेने के करीब, लेकिन मेरा यह है कि कई उपयोगकर्ताओं की तालिका का भंडारण वास्तव में आकस्मिक है, और यह कि किसी भी एकवचन उपयोगकर्ता को तालिका द्वारा दर्शाया जाता है, या बल्कि संबंध जो उपयोगकर्ता इकाई का प्रतिनिधित्व करने वाले ट्यूपल्स का एक सेट है।
— 8
मुझे लगता है कि मैं इससे सहमत हूं। केवल एक चीज मुझे भ्रमित करती है कि मॉडल एकवचन क्यों होना चाहिए? केवल अगर मॉडल केवल एक उपयोगकर्ता के साथ संबंध है। अगर मैं सभी उपयोगकर्ताओं को पाने के लिए db को क्वेरी कर रहा था तो क्या मुझे मॉडल तक पहुंचने की आवश्यकता होगी? यह सभी रिकॉर्ड लाने के लिए एक विलक्षण उदाहरण के लिए कोई मतलब नहीं है, उदाहरण: $ user-> get_all () // मतलब नहीं है
— PM7Temp
12

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

http://www.aisintl.com/case/method.html

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

— शेन डेलमोर
स्रोत
1
एक 'प्रकार' क्वालीफायर के साथ उपसर्ग वस्तु नामों के नुकसान का अच्छा उदाहरण!
— बजे केनी एविट
12

प्रणाली tables/viewsसर्वर पर ही की ( SYSCAT.TABLES, dbo.sysindexes, ALL_TABLES, information_schema.columns, आदि) लगभग हमेशा बहुवचन है। मुझे लगता है कि मैं उनके नेतृत्व का पालन करूंगा।

— मिशेल
स्रोत
Microsoft वे हैं जो पहले व्यावसायिक कारणों से हैं (और अक्सर उस पर अनैतिक कारण), तार्किक कारण। उनका अनुसरण करने का मेरा एकमात्र कारण यह होगा कि वे बड़े गोरिल्ला हैं और बाकी सभी इस तरह से चलते हैं। जब मेरे पास एक विकल्प होता है, तो मैं दूसरा रास्ता चुनता हूं।
— ब्रूस पाटन
1
यह ध्यान दिया जाना चाहिए कि यह information_schemaISO / IEC 9075-11, SQL मानक का हिस्सा है। और हाँ, यह बहुवचन तालिकाओं / विचारों के नामों का उपयोग करता है।
— पाउलो फ्रीटास
10

यदि हम MS SQL Server'sसिस्टम तालिकाओं को देखते हैं, तो Microsoft द्वारा निर्दिष्ट उनके नाम अंदर हैं plural।

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

मुझे याद है कि अकादमिया में, सिफारिश विलक्षण थी।

उदाहरण के लिए, जब हम कहते हैं:

select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'

शायद बी / सी प्रत्येक IDएक विशेष एकल पंक्ति से चुना गया है ...?

— रिचर्ड
स्रोत
1
Microsoft वे हैं जो व्यावसायिक कारणों से पहले हैं (और अक्सर उस पर अनैतिक कारण), तार्किक कारण। उनका अनुसरण करने का मेरा एकमात्र कारण यह होगा कि वे बड़े गोरिल्ला हैं और बाकी सभी इस तरह से चलते हैं। जब मेरे पास एक विकल्प होता है, तो मैं दूसरा रास्ता चुनता हूं।
— ब्रूस पाटन
दो चीज़ें। एक, आप सामान्य रूप से टेबल नामों का उपयोग नहीं करेंगे और 'ऑर्डर आईडी से चुनिंदा आईडी लिखेंगे जहां संदर्भ =' एबीसी123 'क्योंकि आप' ऑर्डरहेडर्स से सभी आईडी का चयन कर रहे हैं जहां कुछ सत्य है 'लेकिन अगर आपको टेबल नामों का उपयोग करना है तो शामिल हों या जो भी हो, आप जैसे एक उपनाम का उपयोग करेंगे ... 'ऑर्डरHeader.ID से ऑर्डरहेडर्स से ऑर्डरहेडर के रूप में चुनें जहां ऑर्डरहैडर। संदर्भ =' एबीसी123 '
— मार्क ए। डोनोहे
9

यह थोड़ा बेमानी हो सकता है, लेकिन मेरा सुझाव है कि सतर्क रहना चाहिए। जरूरी नहीं है कि तालिकाओं का नाम बदलना एक बुरी बात है, लेकिन मानकीकरण सिर्फ इतना है; एक मानक - यह डेटाबेस पहले से ही "मानकीकृत" हो सकता है, हालांकि बुरी तरह से :) - मैं एक बेहतर लक्ष्य होने के लिए स्थिरता का सुझाव दूंगा कि यह डेटाबेस पहले से मौजूद है और संभवतः इसमें सिर्फ 2 टेबल से अधिक है।

जब तक आप पूरे डेटाबेस को मानकीकृत नहीं कर सकते हैं, या कम से कम उस छोर की ओर काम करने की योजना बना रहे हैं, मुझे संदेह है कि टेबल के नाम सिर्फ हिमखंड की नोक हैं और हाथ में काम पर ध्यान केंद्रित कर रहे हैं, खराब नामित वस्तुओं के दर्द को सहन कर सकते हैं, हो सकता है। आपकी सबसे अच्छी रुचि -

व्यावहारिक स्थिरता कभी-कभी सबसे अच्छा मानक होती है ... :)

my2cents ---

— Borzio
स्रोत
9

संभावित विकल्प:

  • तालिका का नाम बदलें SystemUser
  • कोष्ठक का प्रयोग करें
  • बहुवचन तालिका के नाम रखें।

ब्रैकेट का उपयोग करते हुए IMO तकनीकी रूप से सबसे सुरक्षित दृष्टिकोण है, हालांकि यह थोड़ा बोझिल है। IMO यह 6 में से एक है, दूसरे का आधा दर्जन, और आपका समाधान वास्तव में सिर्फ व्यक्तिगत / टीम वरीयता के लिए उबलता है।

— डेव मार्कल को दर्शाता है
स्रोत
2
मुझे आपका 'उपसर्ग' विचार पसंद है, लेकिन इसे SystemUser कहेंगे।
— प्रोफ
9

आप अपने कंटेनर को कैसे परिभाषित करते हैं, इसके आधार पर मेरा टेक शब्दार्थ में है। उदाहरण के लिए, ए "सेब का बैग" या बस "सेब" या "सेब बैग" या "सेब"।

उदाहरण: "कॉलेज" तालिका में 0 या अधिक कॉलेज हो सकते हैं "कॉलेज" की तालिका में 0 या अधिक कॉलेजियम हो सकते हैं

a "student" table can contain 0 or more students 
a table of "students" can contain 0 or more students.

मेरा निष्कर्ष यह है कि या तो ठीक है, लेकिन आपको यह परिभाषित करना होगा कि आप (या इसके साथ बातचीत करने वाले लोग) तालिकाओं का संदर्भ देते समय कैसे संपर्क करेंगे; "अक्ष तालिका" या "xs की तालिका"

— jleviaguirre
स्रोत
8

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

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

यह अभ्यास मुझे उन लोगों के लिए बहुवचन तालिका नाम आरक्षित करने की अनुमति देता है जो मेरी वस्तुओं के बीच कई-से-कई संबंधों को संग्रहीत करते हैं।

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

मैं एक सीमित तरीके से उपसर्गों का उपयोग करना पसंद करता हूं (तालिका नामों के लिए tbl, खरीद नामों के लिए sp_, आदि), हालांकि कई लोग यह कहते हैं कि यह अव्यवस्था है। मैं कैमलबैक नामों को भी रेखांकित करना पसंद करता हूं क्योंकि मैं हमेशा नाम टाइप करते समय _ के बजाय + को हिट करता हूं। कई अन्य असहमत हैं।

यहाँ कन्वेंशन दिशानिर्देशों के नामकरण के लिए एक और अच्छी कड़ी है: http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-conference/

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

— क्रिस
स्रोत
18
आयु अंकन की भयावहता को अनदेखा करना। कभी नहीं, कभी नहीं, कभी भी संग्रहीत प्रक्रियाओं के सामने sp_ का उपयोग न करें क्योंकि MS-SQL सिस्टम संग्रहीत प्रक्रियाओं के लिए उपयोग करता है और उन्हें विशेष मानता है। चूंकि sp_ को मास्टर टेबल में संग्रहीत किया जाता है, MS-SQL हमेशा स्थान को अर्हता प्राप्त करने पर भी सबसे पहले दिखता है।
— डाइटरीच
8

मुझे लगता है कि एकवचन का उपयोग करना हमें विश्वविद्यालय में सिखाया गया था। लेकिन एक ही समय में आप तर्क दे सकते हैं कि ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग के विपरीत, एक टेबल अपने रिकॉर्ड का उदाहरण नहीं है।

मुझे लगता है कि मैं अंग्रेजी में बहुवचन अनियमितताओं के कारण इस समय एकवचन के पक्ष में हूं। जर्मन में, यह लगातार सुसंगत बहुवचन रूपों के कारण भी बदतर है - कभी-कभी आप यह नहीं बता सकते कि कोई शब्द बहुवचन है या उसके सामने निर्दिष्ट लेख के बिना नहीं है (der / die / das)। और चीनी भाषाओं में वैसे भी बहुवचन रूप नहीं हैं।

— helloworlder
स्रोत
विश्वविद्यालय में मुझे टेबल के लिए बहुवचन सिखाया जाता है, मेरे पास यहां एक पुस्तक भी है, डीबी प्रबंधन तीसरे संस्करण में 90 के दशक से, टेबल एकवचन हैं; जबकि मेरे पास एक अद्यतन प्रति, 11e, एकवचन और कुछ संक्षिप्त नाम हैं, जबकि XML अनुभाग बहुवचन का उपयोग करता है। \ n लेकिन अगर आप आरडीबीएमएस अनुभागों के लिए वास्तविक सामग्री की जाँच करते हैं, तो यह सचमुच अभी भी वही पाठ है जिसमें कुछ छवियों के साथ चेहरा उठा हुआ है। \ n "डेटा मॉडलिंग चेकलिस्ट" बहुवचन बनाम एकवचन पर कुछ भी नहीं बताती है, बस संस्थाओं को केवल एक ही वस्तु के लिए मैप करना चाहिए, शायद यही वे पुस्तकों में लागू करने की कोशिश कर रहे थे।
— मार्को
8

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

— ब्रूस पाटन
स्रोत
8

मैंने हमेशा एकवचन का इस्तेमाल किया है, क्योंकि मुझे यही सिखाया गया था। हालांकि, हाल ही में एक लंबे समय के लिए पहली बार एक नया स्कीमा बनाते समय, मैंने सक्रिय रूप से इस सम्मेलन को केवल इसलिए बनाए रखने का फैसला किया क्योंकि ... यह छोटा है। हर टेबल के नाम के अंत में एक 's' जोड़ना मुझे उतना ही बेकार लगता है जितना कि हर एक के सामने 'tbl_' को जोड़ना।

— जस्ट सी गय
स्रोत
7

मैंने हमेशा सोचा कि यह एक गूंगा सम्मेलन था। मैं बहुवचन तालिका नामों का उपयोग करता हूं।

(मेरा मानना ​​है कि उस नीति के पीछे तर्क यह है कि यह ओआरएम कोड जनरेटर के लिए ऑब्जेक्ट और कलेक्शन क्लास का उत्पादन करना आसान बनाता है, क्योंकि इसके विपरीत एक विलक्षण नाम से बहुवचन नाम का उत्पादन करना आसान है)

— जेम्स क्यूरन
स्रोत
11
यह सम्मेलन ORM कभी अस्तित्व में आने से पहले लंबे, लंबे, संबंधपरक सिद्धांत का हिस्सा रहा है।
— 14
1
ओआरएम को उन वस्तुओं के नामों को निर्देशित नहीं करना चाहिए जिनके लिए वे मैप करते हैं। ORM का बिंदु वस्तु का एक अमूर्त हिस्सा है, जो इस फ्लेक्सिबिलिटी को प्रदान करता है।
— बैरीपिकर
7

मैं केवल अपनी तालिका नामों के लिए संज्ञाओं का उपयोग करता हूं जो समान हैं, चाहे एकवचन या बहुवचन:

मूस मछली हिरण विमान आप पैंट शॉर्ट्स चश्मा कैंची प्रजातियों के वंश

— पुलिसमैन
स्रोत
6

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

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

— jerseyboy
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.