तालिका का नामकरण: अंडरस्कोर बनाम कैमलकेस? नामस्थान? एकवचन बनाम बहुवचन?

Question 1

मैं StackOverflow पर कुछ प्रश्नों / उत्तरों की एक जोड़ी को पढ़ रहा हूँ जो 'सर्वोत्तम' खोजने की कोशिश कर रहे हैं, या मुझे यह कहना चाहिए कि डेटाबेस में तालिकाओं के नाम को स्वीकार करना चाहिए।

अधिकांश डेवलपर्स उस भाषा के आधार पर तालिकाओं का नाम देते हैं जिनके लिए डेटाबेस (JAVA, .NET, PHP आदि) की आवश्यकता होती है। हालाँकि मुझे लगता है कि यह सही नहीं है।

जिस तरह से मैं अब तक तालिकाओं का नामकरण कर रहा हूं वह कुछ ऐसा कर रहा है:

doctorsMain
doctorsProfiles
doctorsPatients
patientsMain
patientsProfiles
patientsAntecedents

मैं जिन चीजों के बारे में चिंतित हूं:

स्पष्टता
मॉड्यूल की त्वरित पहचान तालिका से है (डॉक्टर || मरीज)
भ्रम को रोकने के लिए समझना आसान है।

मैं नामकरण सम्मेलनों के बारे में कोई राय पढ़ना चाहूंगा। धन्यवाद।

Question 2

सुसंगत होना इस बात से कहीं अधिक महत्वपूर्ण है कि आप किस विशेष योजना का उपयोग करते हैं।

Question 3

मैं आमतौर पर PascalCase का उपयोग करता हूं और संस्थाएं एकवचन हैं:

DoctorMain
DoctorProfile
DoctorPatient

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

Question 4

SQL की केस असंवेदनशील प्रकृति समर्थन करती है Underscores_Scheme। आधुनिक सॉफ्टवेयर हालांकि किसी भी प्रकार की नामकरण योजना का समर्थन करता है। हालांकि कभी-कभी कुछ बुरा कीड़े, त्रुटियां या मानव कारक हो सकते हैं UPPERCASINGEVERYTHINGताकि वे, जो दोनों का चयन करते हैं Pascal_Caseऔर Underscore_Caseयोजना अपने सभी तंत्रिकाओं के साथ अच्छी जगह पर रहते हैं।

Question 5

उपरोक्त में से अधिकांश का एक एकत्रीकरण:

डेटाबेस में केस पर भरोसा न करें
नाम के मामले या विभाजक भाग पर विचार न करें - केवल शब्द
जो भी विभाजक या मामला आपकी भाषा के लिए मानक है उसका उपयोग करें

फिर आप आसानी से (यहां तक कि स्वचालित रूप से) नामों को पर्यावरण के बीच अनुवाद कर सकते हैं।

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

Question 6

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

Question 7

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

/ [a-z _] [a-z0-9 _] * * / वास्तव में नामों का एकमात्र पैटर्न है जो मूल रूप से विभिन्न प्लेटफार्मों में अनुवाद करता है। लोअरकेस अल्फा-न्यूमेरिक + अंडरस्कोर हमेशा लगातार काम करेगा।

जैसा कि कहीं और उल्लेख किया गया है, संबंध (तालिका) नाम विलक्षण होना चाहिए: http://www.teamten.com/lawrence/programming/use-singular-nouns-for-database-table-names.html

Question 8

मैं उन लोगों से सहमत हूं जो यह कहते हैं कि यह आपके द्वारा उपयोग की जा रही भाषा के सम्मेलनों पर निर्भर करता है (जैसे C # के लिए PascalCase और रूबी के लिए snake_case)।

हालांकि, कभी कैमलकेस नहीं।

Question 9

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

Question 10

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

अंडरस्कोर का उपयोग करें।
उद्धरण के साथ ऊंट मामले का उपयोग करें।

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

Question 11

दुर्भाग्य से इस प्रश्न का कोई "सर्वश्रेष्ठ" उत्तर नहीं है। जैसा कि @ डेविड ने कहा कि नामकरण सम्मेलन की तुलना में कहीं अधिक महत्वपूर्ण है।

Question 12

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

Question 13

किसी भाषा के दायरे में नामकरण परंपराएँ मौजूद हैं, और विभिन्न भाषाओं में अलग-अलग नामकरण परंपराएँ हैं।

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

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