बहुवचन बनाम एकवचन तालिका नाम

41

नया डेटाबेस बनाते समय मुझे अपने टेबल्स का नाम कैसे देना चाहिए?

एकवचन: Clientया बहुवचन Clients:?

database-design naming-convention

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

— रेने Nyffenegger

1

विचार के अन्य विद्यालय हैं। 1) ऐसी क्रियाओं का उपयोग करें जो प्राकृतिक भाषा में प्रश्नों को व्यक्त करने की अनुमति देगा जैसे person NAMED 'fred' EARNS 20,000(जहां अपरकेस नाम टेबल हैं)। 2) सेट उदाहरण के लिए उद्यम के नाम का उपयोग PERSONNEL, PAYROLL, ORG_CHARTआदि,

— onedaywhen

3

संभावित क्रॉस साइट डुप्लिकेट: stackoverflow.com/questions/338156/…

— Ciro Santilli 中心:::

44

आप पर निर्भर करता है। हालांकि लगातार हो।

व्यक्तिगत रूप से मैं प्रत्येक * पंक्ति "स्टोर के आधार पर एकवचन पसंद करता हूं: ऑर्डर, उत्पाद, उपयोगकर्ता, आइटम, आदि।

यह मेरे मॉडलिंग (ऑब्जेक्ट रोल मॉडलिंग के माध्यम से) से मेल खाता है जहां मैं एकवचन संस्थाओं / प्रकारों का उपयोग करता हूं।

संपादित करें:

एक कारण यह है कि बहुवचन में विफल रहता है आप लिंक टेबल है जब है:
Orders, Productsदेना होगा OrderProductsया OrdersProducts। न ही सही लगता है

या इतिहास टेबल (बेशक आप इसके लिए स्कीमा का उपयोग कर सकते हैं):
Orders-> OrdersHistoryया (नहीं!) OrdersHistories। नहीं होगा Order-> OrderHistoryबेहतर होगा?

— GBN
स्रोत

2

क्या इसे हमेशा एक व्यक्तिगत पसंद के लिए उबालना चाहिए ? क्या हुआ अगर एक डेटाबेस डिज़ाइन में 2 लोग काम कर रहे थे, तो एक का नाम तालिकाओं के रूप में हो सकता है और दूसरा एकवचन के रूप में। क्या इसका उपयोग Singularया करने के लिए कोई मान्य तर्क नहीं है Plural?

— जॉन यशायाह कार्मोना

2

@ जोहानिसाहैर्मोना: ने एक कारण जोड़ा

— gbn

3

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

— जोएल ब्राउन

4

सिंगुलर के पक्ष में एक और कारण यह है कि यदि आपके पास नियम है कि पीके का नाम टैबलेन के नाम पर रखा गया है, उदाहरण के लिए TablenameIDया TablenameCodeया tablename_id। बहुवचन तालिका नामों के साथ, आप Orders.OrdersID(जो सही नहीं लगते हैं) के साथ समाप्त होते हैं या Orders.OrderIDजहां आप तालिका नामों के लिए बहुवचन का उपयोग करते हैं, लेकिन स्तंभ उपसर्गों के लिए एकवचन में बदल जाते हैं।

— ypercube y

इसी तर्ज पर एक और बिंदु ।

— जैक डगलस

8

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

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

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

यदि आप कार्यक्रम में एक संग्रह की पहचान करना चाहते हैं, तो आप एक बहुवचन का उपयोग कर सकते हैं, या बेहतर, एक उपयुक्त संशोधक का उपयोग कर सकते हैं, जैसे कि EmployeeList या EmployeeArray।

स्वचालित कोड पीढ़ी और प्रोग्रामर के लिए अनियमित प्लुरल के साथ एक समस्या है, जिनके पास एक प्रोग्राम में विभिन्न भाषाओं की पृष्ठभूमि या विचार हैं, जो प्लुरल के गठन के बारे में हैं।

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

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

5

जैसा कि @ gbn का उत्तर मुझे लगता है कि यह सबसे अधिक प्राथमिकता का विषय है और उसके जैसा ही मैं आपको सलाह देता हूं कि जो भी विकल्प आपने बनाया है, उसे हर जगह (उस DB में कम से कम) लागू करें। संगति इसके लायक है।

मेरी प्राथमिकता, हालांकि यह है कि एक बहुवचन SELECTबयानों में बेहतर लगता है :

SELECT Id, Name, Status 
FROM   Persons
WHERE  Status <> 5  --5 meaning deleted

मेरा मतलब है कि इस मामले में, कम से कम, तालिका में कई व्यक्ति हैं और उनमें से कई ग्राहक को लौटाए गए हैं।

— आंद्रेई रोनेया
स्रोत

2

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

— Mr.Brownstone

5

"आदेश" एक आरक्षित शब्द है। "आदेश" नहीं है

"उपयोगकर्ता" एक आरक्षित शब्द है। "उपयोगकर्ता" नहीं है

"सत्र" एक आरक्षित शब्द है। "सत्र" नहीं है

"परिणाम" एक आरक्षित शब्द है। "परिणाम" नहीं है

"सापेक्ष" एक आरक्षित शब्द है। "रिश्तेदार" नहीं है

...

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

— नील मैकगिगन
स्रोत

1

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

— Emacs यूजर

"स्पष्टता के बहुत करीब" का क्या मतलब है?

— नील मैकगिगन

1

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

— Emacs यूजर

IMO PurchaseOrder, PortalUser, UserSession सिर्फ ऑर्डर से बेहतर है, उपयोगकर्ता, सत्र इसलिए एकवचन इस परिदृश्य में ठीक कर सकता है

— जॉन जय

1

मेरा मानना है कि SQL टेबल में बहुवचन नाम होना चाहिए। यह बस बहुत बेहतर पढ़ता है।

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

इससे कोडिंग अधिक स्वाभाविक हो जाती है।

select name, publication_date from books where publication_date > '2000-01-01';

books = Books()
for book in books.get("publication_date >= '2000-01-01'"):
    print book.name

— dlink
स्रोत

तब तक समझ में आता है जब तक कि आपको सीप में भेड़ के लिए लिखना नहीं पड़ता है ... झुकना नियम, लचीला होना।

— Emacs यूजर

यह सच है कि कुछ कंटेनर संज्ञा जैसे गैर-बहुवचन के साथ शब्द हैं - जैसे 'पहुंच'। लेकिन एक का उपयोग कर संशोधित कर सकते हैं: 'access_record in access' के लिए।

— dlink

हालांकि लिंक वस्तुओं को देखकर मुझे थोड़ी बैचेनी होती है। पुस्तकों और लेखकों के बीच लिंक तालिका के बारे में कैसे? "बुकअथर्स" देखने और सुनने में भयानक लगता है, लेकिन "बुकऑथोर" बेहतर लगता है और लगता है। फिर आप ऐसे शब्दों में शामिल हो जाते हैं, जिनमें बहुवचन (स्थिति) के लिए विषम अंत होता है या अनियमित संज्ञाएं होती हैं (बच्चे बनाम बच्चे)। आईएमओ आँख दर्द की दुनिया!

— बूँद

हाय, @blobbles बहुवचन BookAuthors होगा, BooksAuthors नहीं। तो यह अभी भी प्राकृतिक पढ़ता है। BookPublishers, BookFormats, इत्यादि

— dlink

पठनीयता हमेशा अच्छी होती है, लेकिन यह उन वाक्यों के बारे में नहीं है जो उन जगहों के बारे में हैं जिनसे हम डेटा प्राप्त कर रहे हैं। उदाहरण के लिए table.field, author.authorNameयह पूरी तरह से ठीक है। लेखक तालिका से लेखक का नाम प्राप्त करें। जब केवल एक लेखक होता है, तो बहुवचन बहुत बुरा लगता है। authors.authorNameजब केवल एक लेखक होता है? यह अधिक भ्रामक है imo। यह निश्चित रूप से बेहतर बना है अब हम वाक्य शैली mysql_ के साथ दूर हो गए हैं और डेटा तक पहुंचने के बेहतर तरीके हैं :)

— जेम्स

1

कुछ वर्षों के लिए प्रोग्रामिंग के साथ काम करने के बाद मैंने निष्कर्ष निकाला है कि बहुवचन एक अनावश्यक जटिलता है। मेरी राय है कि KISS दर्शन के अनुसार एक प्रोग्रामर समय और दक्षता कारणों से सभी समस्याओं को laziest और सबसे आसान समाधान के लिए प्रयास करना चाहिए है। इस प्रकार एकवचन आपको सभी परिदृश्यों में आवश्यक कम काम देता है।

— ColacX
स्रोत

यह उत्तर वास्तव में पूरे धागे में कुछ भी नहीं जोड़ता है! आप उदाहरण के लिए एक टेबल "ऑर्डर" कॉल करने के साथ समस्या का जवाब देने में विफल रहते हैं! व्यक्तिगत रूप से, मैं फ्रांसीसी शब्दों का उपयोग करता हूं जब अंग्रेजी चाल नहीं करेगा - ordre, groupe ... हमेशा अपनी पसंद समझाने के लिए अपनी तालिका के टिप्पणी क्षेत्र का उपयोग करें! लेकिन, वास्तव में महत्वपूर्ण बात यह है कि एक सम्मेलन और इसके साथ रहना है !

— 10

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

— ColacX

0

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

— रे
स्रोत

0

हम विभिन्न दृष्टिकोणों से चीजों को देखते हैं, और मुझे लगता है कि दो शिविरों की पहचान की गई है:

एकवचन ("उपयोगकर्ता")
वह व्यक्ति जो तालिका के नाम और तथ्य के बीच संबंध बनाता है, वह एक कंटेनर का प्रतिनिधित्व करता है, जिसमें कई पंक्तियाँ हो सकती हैं।

तो "उपयोगकर्ता कंटेनर" में कई पंक्तियाँ हो सकती हैं।

बहुवचन ("उपयोगकर्ता")
वह व्यक्ति जो तालिका नाम के बीच संबंध नहीं बनाता है और यह तथ्य कि यह एक कंटेनर का प्रतिनिधित्व करता है। बेशक वे जानते हैं कि यह एक कंटेनर है, लेकिन यह नाम में नहीं है।

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

मुझे लगता है कि यह बहुवचन के वर्षों के आम व्यवहार और अधिकांश ऑनलाइन शिक्षण सामग्री के कारण भी है।

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

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

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

— जेम्स
स्रोत