क्या बहुत संक्षिप्त तालिका नामों का उपयोग करने का कोई कारण है?


22

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

तालिका नाम aptrx (खाता देय लेनदेन) और apmaster_all की तरह हैं (उत्सुकता से, यह विक्रेताओं की तालिका है)। यह एक अत्यंत जटिल डेटाबेस है, इसलिए मैं सोच रहा था कि क्या सम्मेलन में कोई तर्क था या यदि यह जानबूझकर या अन्यथा बाधित किया गया था।

मेरे ज्ञान का सबसे अच्छा करने के लिए तालिका के नाम की लंबाई प्रदर्शन को प्रभावित नहीं करेगा, सही? डेटाबेस बहुत जटिल है (सैकड़ों टेबल) इसलिए छंटाई समझ में आती है, लेकिन मैं कल्पना नहीं कर सकता कि क्यों एकाउंटपेबल ट्रांज़ेक्शंस aptrx के लिए बेहतर नहीं है ...।


8
किसी को बेहतर जानने के लिए काफी मुश्किल से सिर के पिछले हिस्से में धूम्रपान नहीं किया गया
DForck42

2
* smirks * यह नौकरी की सुरक्षा के लिए है, पुराने प्रोग्रामर को फायर करने और नए नाम रखने की लागत बहुत अधिक हो जाती है यदि आपके पास गुप्त नाम हैं।
रेयान

@ Lie_Ryan जो निश्चित रूप से ऐसा प्रतीत होता है, कि वे आशा करेंगे कि आप एक सलाहकार को नियुक्त करेंगे ...
बेन ब्रोका

FWIW, यदि आप लेखा प्रणालियों पर काम करते हैं, तो "aptrx" गुप्त नहीं है। यह स्पष्ट है। नीचे मेरे जवाब में अधिक जानकारी।
माइक शेरिल 'कैट रिकॉल'

मोटापा एक कारण है
अरनौद ले ब्लैंक

जवाबों:


23

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

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


2
यदि 30 अक्षर तालिकाओं के लिए अद्वितीय नामों के साथ आने के लिए पर्याप्त नहीं हैं, तो आपके पास किसी भी DBMS या विकास के वातावरण की तुलना में बहुत अधिक गंभीर समस्या हल हो सकती है: आपको अपनी भाषा और / या की अभिव्यक्ति के स्तर के साथ समस्या है शब्दावली।
एरविन स्मौट

18

मुझे लगता है कि दो चीजें हैं जिन्हें अभी भी कहा जाना चाहिए या विस्तृत होना चाहिए:

  1. चीजों को नाम देना उतना तुच्छ नहीं है जितना लगता है

    कंप्यूटर विज्ञान में केवल दो कठिन समस्याएं हैं: कैश अमान्यकरण और नामकरण की चीजें। फिल कार्लटन

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

मुझे हमेशा नाम चुनने में बहुत कम समय बिताने का लालच होता है, और बाद में अगर मैं करता हूं तो हमेशा पछताता हूं - नाम बदलना केवल शायद ही कभी होता है


2
मैं नामों के बारे में बहुत अछूता हूं और मेरी वर्तमान सीमित क्षमता उन्हें बदलने के लिए मुझे कोई अंत नहीं है। मैं हालांकि UX में हूं, इसलिए गैर-उपयोग करने योग्य नाम मुझे विशेष रूप से बग कर सकते हैं। इसके अलावा मैं सिर्फ ऊंट पसंद करते हैं ...
बेन ब्रोका

7

आलस्य। IntelliSense और 3rd पार्टी विकल्प सही ठहराने के लिए एक वास्तविक कठिन बहाना बनाते हैं। मैं बहुत बल्कि नाम सार्थक और पठनीय शब्द हैं।


6

तालिका नाम aptrx (खाता देय लेनदेन) और apmaster_all की तरह हैं (उत्सुकता से, यह विक्रेताओं की तालिका है)। यह एक अत्यंत जटिल डेटाबेस है, इसलिए मैं सोच रहा था कि क्या सम्मेलन में कोई तर्क था या यदि यह जानबूझकर या अन्यथा बाधित किया गया था।

आमतौर पर जाने-माने संक्षिप्ताक्षर चीजों को वर्तनी के लिए बेहतर होते हैं। जब एक संक्षिप्त नाम कुछ लोगों के लिए जाना जाता है, लेकिन काफी लोग नहीं हैं, तो हम इसे संक्षिप्त नाम देना बंद कर देते हैं, और इसे एक कोड कहना शुरू करते हैं।

संकेताक्षर उन प्लेटफार्मों पर स्थान का संरक्षण करते हैं जिनकी तंग सीमाएं हैं, हालांकि यह 30 साल पहले की तुलना में अब कम महत्वपूर्ण है। (मुझे लगता है कि 1980 के दशक में एक प्रणाली पर काम करना याद है जो आपको तालिका नाम के लिए 6 या 8 वर्णों तक सीमित करता है।)

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

लेखांकन प्रणालियों में, "एपी" और "ट्रक्स" दोनों ही प्रसिद्ध परिप्रेक्ष्य हैं। दूसरों में प्राप्य, सामान्य खाता बही और सामान्य पत्रिका के लिए "ar", "gl" और "gj" शामिल हैं।

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

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

मैं इस आपत्ति को नहीं कहूंगा। लेखा देय लेनदेन "cdrs21" नाम की एक तालिका में संग्रहीत कर रहे थे, मैं फोन करता हूँ कि कहानियो। (हालांकि मैंने एक बार एक कंपनी के लिए काम किया था जिसने अपने सभी मेनफ्रेम असेंबलर मॉड्यूल को उस तरह से नाम दिया था। चरित्र सीमाएं, न कि आपत्ति।)

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


4
समस्या का एक हिस्सा यह है कि इन तालिकाओं को लेखाकारों द्वारा बनाए नहीं रखा जा रहा है, उन्हें एक सिस्टम विश्लेषक द्वारा बनाए रखा जा रहा है और आम तौर पर हमारे आईटी विभाग। aptrx वास्तव में सबसे तार्किक नामों में से एक है जो मैंने पाया है, केवल एक मैं। 've याद । यह भी ध्यान दें कि कई सौ टेबल हैं; "देय" के लिए "एपी" जैसे बुनियादी संक्षिप्तीकरण सीखना बहुत आसान है, "एपी" के बाद शाब्दिक 100 प्रत्यय नहीं हैं ...
बेन ब्रोका

4

बस "मेरे भगवान, काले चश्मे के साथ वे इस भयानक नामकरण सम्मेलन" कहानी के लिए कुछ नहीं करते हैं। मेरे अंतिम वातावरण में डेटा प्रबंधन टीम ने कहा कि संक्षिप्त तालिका नामों का उपयोग करने का कारण तालिका और स्तंभों के लिए 18 वर्णों का DB2 सीमा (z / os और SQL सर्वर पर DB2 था) था। मैंने तुरंत बताया कि यह आईबीएम की साइट से प्रलेखन के साथ गलत था। फिर उन्होंने कहा कि यह एक COBOL मुद्दा था (हाँ, उन्हें सक्रिय रूप से COBOL विकसित किया गया था) अगर इसे उस डेटाबेस से बात करने की आवश्यकता होती है जो तब MF जॉकी द्वारा नापसंद किया गया था। अंत में, उनकी प्रतिक्रिया यह हमारा प्रकाशित मानक था।

हमने 18 से 32 चरित्र की लंबाई बढ़ाने के लिए मानक समिति की याचिका दायर की और 30 चरित्र सीमा प्राप्त की। इसके परिणामस्वरूप तालिकाएँ 'SR_M_DLY_ADV_PRD_S' के बेकार नामों से 'IDX_FDSHRCLAS_LIF_RTRN_STATS_X' FML तक चली गईं

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


1
ऐसा लगता है कि नाम पूरी तरह से बेकार नामों से थोड़ा कम बेकार नामों तक जाता है। शायद सामान्यीकरण मदद कर सकता है? यदि प्रत्येक तालिका कम करती है, तो लंबे मल्टीवर्ड नाम रखने के कम कारण हैं, इसलिए संक्षिप्त करने के कम कारण।
रेयान

वास्तव में नहीं, यदि वह कोशिश करता तो अप्रिय रूप से लंबी तालिका कम नहीं कर सकता था। इसमें 4 कॉलम हैं, जिनमें से 2 विदेशी कुंजी थे। यह किसी के लिए "वापसी के आंकड़े" तालिका है, लेकिन ज्ञान के पवित्र डेटा शब्दकोशों की रक्षा करने वाले। यह इंडेक्स फंड शेयर क्लास लाइफटाइम रिटर्न आंकड़े क्रॉस रेफरेंस टेबल है।
बिलसिंक

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

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

3

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


2

मुझे पोस्टरों द्वारा पूर्वोक्त कारणों से वर्णनात्मक नामकरण का उपयोग करना पसंद है।

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


0

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


चूंकि टेबल कोई गैर-स्वचालित मेटाडेटा प्रदान नहीं करते हैं, इसलिए मुझे यकीन नहीं है कि यह एक वैध तर्क है ...
बेन ब्रोका
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.