इकाई नाम बनाम तालिका नाम

Question

हम विरासत डेटाबेस (.NET C# का उपयोग करके) पर एक नई प्रणाली विकसित करने जा रहे हैं। लगभग 500 टेबल हैं। हमने अपनी डेटा एक्सेस लेयर के लिए ओआरएम टूल का उपयोग करना चुना है। समस्याएं संस्थाओं के लिए नामिग सम्मेलन के साथ है।

डेटाबेस में तालिकाओं में TB_CUST जैसे नाम हैं - ग्राहक डेटा के साथ तालिका, या TP_COMP_CARS - कंपनी कारें। उपसर्ग का पहला अक्षर मॉड्यूल को परिभाषित करता है और दूसरा अक्षर अन्य तालिकाओं के साथ अपने संबंधों को परिभाषित करता है।

मैं संस्थाओं को अधिक सार्थक नाम देना चाहता हूं। TB_CUST की तरह ग्राहक या ग्राहक एंटीटी। निस्संदेह एक टेबल टिप्पणी के लिए एक टिप्पणी होगी।

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

लेकिन TP_COMP_CARS जैसे इकाई नाम के मामले में Get TP_COMP_CARS या SaveTP_COMP_CARS जैसे विधियों के नाम होना चाहिए .. मुझे लगता है कि यह अपठनीय और बदसूरत है।

तो कृपया मुझे अपनी राय बताएं। कौन सही है और क्यों।

अग्रिम

Answer 1

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

हालांकि यह व्यक्तिपरक है, मेरी राय में आप सही हैं और वह गलत है ....

Answer 2

कौन नए कोड के साथ ज्यादातर काम करने के लिए जा रहा है? उस व्यक्ति को नामकरण सम्मेलन आईएमएचओ तय करना चाहिए।

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

Answer 3

एक समझौता के रूप में आप TB_CUST जैसे नामों का उपयोग कर सकते हैं जहां सीधे डेटाबेस के साथ कार्य करते हैं लेकिन फिर अपने डेटा ट्रांसफर ऑब्जेक्ट्स के लिए ग्राहक जैसे नामों का उपयोग करें। अच्छे कोड को लिखने में आपके द्वारा काम कर रहे किसी भी डेटा स्रोत का एक अमूर्त बनाना शामिल है। GetTB_CUST() अपने पूरे कोड में जगह के चारों ओर बिखरे हुए GetTB_CUSTFromThatSQLDatabaseWeHave() है।

Answer 4

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

और, वास्तव में, चलो ...

Customer == TB_CUST 

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

Answer 5

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

Answer 6

"मैं उसकी वास्तव में OOP के सिद्धांतों से परिचित नहीं कहने के लिए प्राप्त करें TP_COMP_CARS या SaveTP_COMP_CARS..I की तरह लगता है कि यह पढ़ने योग्य नहीं है।

लेकिन TP_COMP_CARS की तरह एक इकाई नाम के मामले में होना चाहिए तरीकों के नाम और बदसूरत।

तो कृपया मुझे अपनी राय बताएं। कौन सही है और क्यों। "

आपके आईटी सिस्टम प्रबंधन की चीजों को कौन से नाम दिए गए हैं, "ओओपी के सिद्धांतों" से बिल्कुल कुछ नहीं करना है।

वही धारण करता है जिसके लिए नाम "मानक" "गेटटर और सेटर" विधियों को दिए जाते हैं: वे केवल समझौते और सम्मेलन हैं, न कि "ओओपी के सिद्धांत"।

यह मुद्दा कोड का एक निश्चित प्रकार "एर्गोनॉमिक्स" (और इस प्रकार स्वयं-दस्तावेज़ मूल्य) है।

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

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

अब से बीस साल, लोग नामकरण सम्मेलनों को कॉल करेंगे जिन्हें हम इन दिनों "ब्राइंडेड" का भी उपयोग करते हैं।

Answer 7

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

जब आप अगली 500 ORM ऑब्जेक्ट्स बनाते हैं - तो आपको एक और चुनौती होगी। भले ही आप उन्हें सार्थक नाम दें, फिर भी वास्तव में उम्मीद है कि सभी स्पष्ट होंगे। तो, अब आपको 2 समस्याएं हैं।

यदि 500 ​​तालिकाओं के उन दो सेटों को एक साथ जोड़ने का कोई तरीका नहीं है - तो आपको 3 समस्याएं मिलेंगी। ओआरएम में प्रश्नों के प्रदर्शन को डीबग करने के बारे में सोचें, और उन नामों के साथ डीबीए में जाएं जिन्हें वह पहचान नहीं पाए। अपने ध्यान से तैयार किए गए नामों के बारे में सोचें - तब जब आप सीधे डेटाबेस को हिट करते हैं तो रिपोर्ट बनाते समय अनदेखा किया जाना चाहिए।

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

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