sql - टेबल नामकरण दुविधा:एकवचन बनाम बहुवचन नाम




sql-server naming-conventions (25)

अकादमिक में यह है कि तालिका के नाम उस इकाई का एकवचन होना चाहिए जो वे गुणों को संग्रहित करते हैं।

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

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

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


Answers

As others have mentioned here, conventions should be a tool for adding to the ease of use and readability. Not as a shackle or a club to torture developers.

That said, my personal preference is to use singular names for both tables and columns. This probably comes from my programming background. Class names are generally singular unless they are some sort of collection. In my mind I am storing or reading individual records in the table in question, so singular makes sense to me.

This practice also allows me to reserve plural table names for those that store many-to-many relationships between my objects.

I try to avoid reserved words in my table and column names, as well. In the case in question here it makes more sense to go counter to the singular convention for Users to avoid the need to encapsulate a table that uses the reserved word of User.

I like using prefixes in a limited manner (tbl for table names, sp_ for proc names, etc), though many believe this adds clutter. I also prefer CamelBack names to underscores because I always end up hitting the + instead of _ when typing the name. Many others disagree.

Here is another good link for naming convention guidelines: http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/

Remember that the most important factor in your convention is that it make sense to the people interacting with the database in question. There is no "One Ring to Rule Them All" when it comes to naming conventions.


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

उन्होंने मेटाडेटा नामकरण के लिए मानक के रूप में ISO-11179-4 हवाला दिया, जो इस दिशानिर्देश का समर्थन करता है।

मुझे तर्क दें कि यह समझ में क्यों आता है।

  1. टेबल एक सेट है। तालिका में प्रत्येक पंक्ति एक वस्तु (कॉलम = फ़ील्ड) है। प्रोग्रामिंग में, आप बहुवचन नामों का उपयोग करके संग्रहों का नाम देते हैं ( Arrays और संग्रहों में बहुवचन नाम होना चाहिए यह इंगित करने के लिए कि वे एकल वस्तुओं की बजाय वस्तुओं का संग्रह हैं ), उदाहरण के लिए जावा प्रोग्राम में args
  2. जावा तर्क बहुवचन में तर्क देते हैं क्योंकि वे 0, 1, और लाखों तर्कों को पकड़ सकते हैं।
  3. आप for every student in students उन्हें दोबारा शुरू करते हैं, न for every s in student किसी के for every s in student । आप छात्रों के एक समूह से छात्रों का एक सबसेट चुनते हैं। आप छात्र से छात्रों का सबसेट नहीं चुनते हैं। उचित नामकरण के लिए यह वैचारिक कारण है।

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

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

ऐप्पलबैग => BagOfApples को परिवर्तित करने दें। अब, वही "वैचारिक" तर्क स्वयं के विपरीत कुछ कहता है, हम ऐप्पल देखते हैं और इसलिए जवाब बहुवचन होना चाहिए!

ऐसा इसलिए है क्योंकि इस **** में कुछ भी वैचारिक नहीं है। यह अंग्रेजी भाषा, सरल तर्क के कारण भी विफल रहता है। अंग्रेजी में, एक BagOfApples != AnApple !

तर्क "बैग में 0,1, .. लाखों" सेब साबित करते हैं कि संग्रह को "सेब" कहा जाना चाहिए, इसी तरह जावा तर्क या .com/posts । किसी भी तरह, सभ्यता के दुश्मन यह निष्कर्ष निकालने का प्रबंधन करते हैं कि एकवचन का उपयोग यहां किया जाना चाहिए। पोस्ट सिर्फ एक फ़ोल्डर है। यह बहुवचन क्यों होना चाहिए?

चलो श्रीमान सिखाओ। आर्टूवुड कुछ तर्क: folder is a folder and must describe what it contains, not how much data it contains

वास्तव में, यदि आप सोचना शुरू करते हैं तो आपको एहसास होता है कि apple contains apple का बकवास होता है। असली अवधारणा यह है कि Bag contains Apples । या तो हम अपने कंटेनर बैग (विशिष्ट प्रकार के) का नाम देते हैं या सोचते हैं कि इसमें क्या शामिल है, सेब (उन गंदे बास्टर्ड ने संख्या को समस्या को कम करने की कोशिश की। लेकिन हम सेब के बाद हैं, न कि उनकी संख्या।)। हां, अगर हम रैपर को दूर करते हैं, तो हम महसूस करते हैं कि हम Apples बाद हैं, इसमें क्या शामिल है। हम या तो एक बैग या सेब, फिर सेब नहीं लेते हैं।

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

ग्राहक आदेश उपयोगकर्ता स्थिति समाचार

वह किस सुविधा के बारे में बात कर रहा है? आइए बस यह इंगित करें कि बहुवचन एकवचन से सरल हो गया है।

कारण 3 । (सौंदर्यशास्त्र और आदेश)।

सौंदर्यशास्त्र हमारी तरफ है। यह आसान है, जैसा कि उसने किया था। हम सिर्फ दावा करते हैं और तालिका को चालू करने के लिए यही आवश्यक है।

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

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

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

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

के रूप में

SELECT गतिविधि। नाम SELECT गतिविधियों .name से बेहतर पढ़ता है

आपको शायद SELECT student.name FROM students as student जरूरत है

ठीक है, यहां शायद तर्क है: तालिका बहुवचन है यदि तालिका बहुवचन है? ठीक है, यह कुछ समझ में आता है। लेकिन कह रहे हैं कि कॉलम (ऑब्जेक्ट की विशेषता) एकवचन है, इसलिए, ऑब्जेक्ट संग्रह एकवचन होना चाहिए, बकवास है।

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

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

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

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

यह तर्क इस बात का समर्थन करता है कि हमें अपने मानव संचार में बहुवचन को क्यों छोड़ना चाहिए। नहीं, moooo, mo moo, moo moo बजाय moooo, mo moo, moo moo , हम कहेंगे I, III, III, II । एकवचन प्रस्ताव के मुकाबले बहुत छोटा है।

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


I personaly prefer to use plural names to represent a set, it just "sounds" better to my relational mind.

At this exact moment i am using singular names to define a data model for my company, because most of the people at work feel more confortable with it. Sometimes you just have to make life easier to everyone instead of imposing your personal preferences. (that's how i ended up in this thread, to get a confirmation on what should be the "best practice" for naming tables)

After reading all the arguing in this thread, i reached one conclusion:

I like my pancakes with honey, no matter what everybody's favorite flavour is. But if i am cooking for other people, i will try to serve them something they like.


मैं अनन्य संज्ञा का उपयोग करना पसंद करता हूं , जो अंग्रेजी में एकवचन होता है।

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

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

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


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

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

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

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

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


The system tables/views of the server itself ( SYSCAT.TABLES , dbo.sysindexes , ALL_TABLES , information_schema.columns , etc.) are almost always plural. I guess for the sake of consistency I'd follow their lead.


I always thought that was a dumb convention. I use plural table names.

(I believe the rational behind that policy is that it make it easier for ORM code generators to produce object & collection classes, since it is easier to produce a plural name from a singular name than vice-versa)


Possible alternatives:

  • Rename the table SystemUser
  • Use brackets
  • Keep the plural table names.

IMO using brackets is technically the safest approach, though it is a bit cumbersome. IMO it's 6 of one, half-a-dozen of the other, and your solution really just boils down to personal/team preference.


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

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


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

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

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

AppUserGroup संबंध मुझे बताता है कि कौन सी संस्थाएं AppUserGroups

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

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

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

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

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


My take is in semantics depending on how you define your container. For example, A "bag of apples" or simply "apples" or an "apple bag" or "apple".

Example: a "college" table can contain 0 or more colleges a table of "colleges" can contain 0 or more collegues

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

My conclusion is that either is fine but you have to define how you (or people interacting with it) are going to approach when referring to the tables; "ax table" or a "table of xs"


I only use nouns for my table names that are spelled the same, whether singular or plural:

moose fish deer aircraft you pants shorts eyeglasses scissors species offspring


I don't like plural table names because some nouns in English are not countable (water, soup, cash) or the meaning changes when you make it countable (chicken vs a chicken; meat vs bird). I also dislike using abbreviations for table name or column name because doing so adds extra slope to the already steep learning curve.

Ironically, I might make User an exception and call it Users because of USER (Transac-SQL) , because I too don't like using brackets around tables if I don't have to.

I also like to name all the ID columns as Id , not ChickenId or ChickensId (what do plural guys do about this?).

All this is because I don't have proper respect for the database systems, I am just reapplying one-trick-pony knowledge from OO naming conventions like Java's out of habit and laziness. I wish there were better IDE support for complicated SQL.


This may be a bit redundant, but I would suggest being cautious. Not necessarily that it's a bad thing to rename tables, but standardization is just that; a standard -- this database may already be "standardized", however badly :) -- I would suggest consistency to be a better goal given that this database already exists and presumably it consists of more than just 2 tables.

Unless you can standardize the entire database, or at least are planning to work towards that end, I suspect that table names are just the tip of the iceberg and concentrating on the task at hand, enduring the pain of poorly named objects, may be in your best interest --

Practical consistency sometimes is the best standard... :)

my2cents ---


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

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


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

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

बनाम

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

बाद में एसक्यूएल अजनबी पूर्व की तुलना में बज रहा है।

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


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

हम डेटाबेस आर्किटेक्चर और एप्लिकेशन आर्किटेक्चर दोनों के बीच एकरूपता प्रदान करने के लिए ऐसा करते हैं, अंतर्निहित समझ के साथ कि उपयोगकर्ता तालिका उपयोगकर्ता मानों का संग्रह है जितना कोड आर्टिफैक्ट में उपयोगकर्ता संग्रह उपयोगकर्ता ऑब्जेक्ट का संग्रह है।

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


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


I've always used singular simply because that's what I was taught. However, while creating a new schema recently, for the first time in a long time, I actively decided to maintain this convention simply because... it's shorter. Adding an 's' to the end of every table name seems as useless to me as adding 'tbl_' in front of every one.


I've actually always thought it was popular convention to use plural table names. Up until this point I've always used plural.

I can understand the argument for singular table names, but to me plural makes more sense. A table name usually describes what the table contains. In a normalized database, each table contains specific sets of data. Each row is an entity and the table contains many entities. Thus the plural form for the table name.

A table of cars would have the name cars and each row is a car. I'll admit that specifying the table along with the field in a table.field manner is the best practice and that having singular table names is more readable. However in the following two examples, the former makes more sense:

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

Honestly, I will be rethinking my position on the matter, and I would rely on the actual conventions used by the organization I'm developing for. However, I think for my personal conventions, I'll stick with plural table names. To me it makes more sense.


IMHO, table names should be plural like Customers .

Class names should be singular like Customer if it maps to a row in the Customers table.


I think using the singular is what we were taught in university. But at the same time you could argue that unlike in object oriented programming, a table is not an instance of its records.

I think I'm tipping in favour of the singular at the moment because of plural irregularities in English. In German it's even worse due to no consistent plural forms - sometimes you cannot tell if a word is plural or not without the specifying article in front of it (der/die/das). And in Chinese languages there are no plural forms anyway.


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

कारण 1 (अवधारणा)। आप "ऐप्पलबैग" जैसे सेब युक्त बैग के बारे में सोच सकते हैं, इससे कोई फर्क नहीं पड़ता कि 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

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

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

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

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

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

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

  • उपयोगकर्ता> लॉग इन यूज़र, ऐप यूज़र, सिस्टम यूज़र, सीएमएसयूसर, ...

या कुख्यात वर्ग वाले ब्रैकेट का उपयोग करें [उपयोगकर्ता]


If we look at MS SQL Server's system tables, their names as assigned by Microsoft are in plural .

The Oracle's system tables are named in singular . Although a few of them are plural. Oracle recommends plural for user-defined table names. That doesn't make much sense that they recommend one thing and follow another. That the architects at these two software giants have named their tables using different conventions, doesn't make much sense either... After all, what are these guys ... PhD's?

I do remember in academia, the recommendation was singular.

For example, when we say:

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

maybe b/c each ID is selected from a particular single row ...?


तालिका में एक नया कॉलम जोड़ें:

ALTER TABLE [table]
ADD Column1 Datatype

उदाहरण के लिए,

ALTER TABLE [test]
ADD ID Int

यदि उपयोगकर्ता इसे स्वचालित रूप से बढ़ाना चाहता है तो:

ALTER TABLE [test]
ADD ID Int IDENTITY(1,1) NOT NULL




sql sql-server naming-conventions