क्या तालिका नामों में 'tbl' उपसर्ग जोड़ना वास्तव में एक समस्या है?

Question

मैं कुछ ब्रेंट ओजर वीडियो देख रहा हूं ( जैसे यह एक, उदाहरण के लिए ) और वह सुझाव देता है कि ‘tbl’या के साथ तालिकाओं का उपसर्ग न करें ‘TBL’।

इंटरनेट पर मैंने कुछ ब्लॉगों को यह कहते हुए पाया कि यह प्रलेखन के लिए कुछ भी नहीं जोड़ता है, और यह भी कि "इसे पढ़ने में अधिक समय लगता है"।

प्रश्न और विचार

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

Comments

काउंटर सवाल: क्या आप अपनी प्रोग्रामिंग भाषा (जावा, सी ++, स्काला, ....) में अपनी सभी कक्षाओं को प्रीफ़िक्स करते हैं Class?

— a_horse_with_no_name

जब उन्हें "इसे पढ़ने में अधिक समय लगता है" तो उनका मतलब प्रदर्शन के मुद्दों से नहीं होता है। मनुष्यों को कोड पढ़ने में अधिक समय लगता है। क्या पढ़ना आसान है? यह वाक्य: Wrdthis wrdis wrda wrdsimple wrdsentence. या यह एक This is a simple sentence.:?

— ypercube y

यह संबंधित हो सकता है: stackoverflow.com/questions/111933/…

— Walfrat

यहाँ इसके खिलाफ एक व्यावहारिक मामला है। सूची में नीचे कूदने के लिए अक्सर तालिका के नाम के पहले अक्षर को लिखना आसान होता है। जब सभी टेबल 't' से शुरू होते हैं जो अब काम नहीं करता है। इसी तरह यह आपकी मदद करने के लिए नहीं जा रहा है IntelliSense के साथ।

— shawnt00

मैं डीबीए नहीं हूं, मैं एक प्रोग्रामर हूं। लेकिन कृपया ऐसा न करें। आप मुझे धीमा कर रहे हैं और मेरे कोड को पढ़ना और बनाए रखना कठिन बना रहे हैं। और किस लिए? मैं किसी भी लाभ को देखने में विफल हूं।

— दाऊद इब्न करीम

Answer 1

मेरे पास एक बार एक मेज थी और यह चमकदार और सुंदर थी। यह एक संगठन के लिए सभी वित्तीय लेनदेन आयोजित करता है। और फिर हमने इसमें डेटा लोड करना शुरू कर दिया।

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

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

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

मैंने तब मूल तालिका के समान नाम के साथ पार्टीशन व्यू बनाया: मासिक। डेटाबेस में किए गए भौतिक परिवर्तन के बारे में कोई भी प्रक्रिया समझदार नहीं थी। कोई रिपोर्ट नहीं टूटी, प्रत्यक्ष अभिगम वाले विश्लेषकों में से किसी ने भी पहले या बाद में उस "तालिका" के साथ कोई समस्या नहीं बताई।

शांत कहानी भाई, लेकिन तुम कहाँ जा रहे हो?

क्या होगा अगर वे वहाँ एक नामकरण सम्मेलन था, tbl_MonthlyAllocation? अब क्या? क्या हम संगठन में हर ईटीएल, हर रिपोर्ट, हर तदर्थ स्प्रेडशीट के माध्यम से जाने वाले बहुत से आदमी घंटे बिताते हैं और vw_MonthlyAllocation का उपयोग करने के लिए उन्हें अपडेट कर रहे हैं? और फिर निश्चित रूप से वे सभी परिवर्तन चेंज बोर्ड के माध्यम से जाते हैं और यह हमेशा एक त्वरित और दर्द रहित प्रक्रिया है।

आप बॉस से पूछ सकते हैं: कंपनी को फिर से काम करने वाले सभी लोगों के लिए क्या इनाम है?

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

या आप अनावश्यक मेटाडेटा के साथ ऑब्जेक्ट्स को डबल एन्कोड नहीं करते हैं। डेटाबेस खुशी से आपको बताएगा कि एक तालिका क्या है, एक दृश्य क्या है, एक टेबल वैल्यू फ़ंक्शन क्या है, आदि।

नामकरण परंपराएं अच्छी हैं, बस अपने आप को उनके साथ एक कोने में पेंट न करें।

Answer 2

यहाँ गया (प्रश्न में आप जिस आदमी का जिक्र कर रहे हैं)।

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

Comments

आप एक डालने के बयान लिख रहे हैं, मैं गंभीरता से आशा है कि आप पहले से ही पता बात आप में डालने रहे हैं एक मेज या एक दृश्य ... है कि क्या

— जो

@ जो: "मुझे आशा है कि आप जानते हैं कि आप जिस चीज को डाल रहे हैं वह एक तालिका या एक दृश्य है" - ऐसी परिस्थितियां हैं जहां आपको एक दृश्य में सम्मिलित किया जा सकता है और आपके कोड को परवाह नहीं करनी चाहिए (कुछ इंजन डेटा के समर्थन में हेरफेर करते हैं सरल पर्याप्त विचारों में, और instead ofट्रिगर इसे अधिक जटिल उदाहरणों के लिए संभव बना सकते हैं)। हालांकि यह अभी भी नाम उपसर्ग की आवश्यकता नहीं है / नहीं होने की ओर इशारा करता है।

— डेविड स्पिललेट

Answer 3

यह एक बहुत ही व्यक्तिपरक तर्क है, लेकिन यहाँ मेरा लेना है: tbl उपसर्ग बेकार है।

आप कोड को कितने परिदृश्यों में देख रहे हैं और आप यह नहीं बता सकते कि कुछ टेबल है या कुछ और?

जब आप ऑब्जेक्ट एक्सप्लोरर में तालिकाओं की एक सूची को देखते हैं, तो इसके अलावा tbl क्या मूल्य जोड़ता है, आप जिस व्यक्ति को खोज रहे हैं उसे खोजने के लिए आपको अधिक काम करना होगा?

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

Comments

उदाहरण के लिए, PostgreSQL में एक दृश्य वास्तव में एक तालिका है, भी: postgresql.org/docs/9.6/static/rules-views.html - इसलिए अंतर और भी कम महत्वपूर्ण है।

— dezso

Answer 4

यह एक भयानक अभ्यास है।

tbl
tbl_
Table_
t_

... उन सभी को उत्पादन में देखा।

जिन उत्पादों में मैं वर्तमान में काम कर रहा हूं उनमें से एक का नाम तालिका के आधे हिस्से में है tbl_whatever, और दूसरे आधे का नाम "सामान्य रूप से" है - उन्हें स्पष्ट रूप से डेवलपर्स मिले हैं जो विभिन्न मानकों पर काम कर रहे हैं। उनकी बुरी आदतों में से एक और स्तंभ नाम उपसर्ग है जो कि विदेशी नामों के साथ हैं fk, इसके बाद तालिका नाम, fkफिर स्तंभ नाम, जैसे भयानक स्तंभ नाम दिए गए हैं fktbl_AlarmsfkAlarmsID। यह नामकरण सम्मेलन पूरे tbl_%मंत्र का एक तार्किक विस्तार है , और आप देख सकते हैं कि यह कितना हास्यास्पद है!

मैं लगभग दूसरे डेटाबेस के बारे में भूल गया जो मुझे दैनिक आधार पर रोता है। स्तंभ नामों को उपसर्ग करने वाले डेटाटाइप्स ... dtPaymentDate, क्योंकि नाम को वास्तव में dtउपसर्ग की आवश्यकता है ? `

Comments

कम से कम आप एक केस सेंसिटिव डेटाबेस के साथ काम नहीं कर रहे हैं, इसलिए tbl_Foo और Tbl_Foo अलग-अलग इकाइयाँ नहीं हैं ...

— बिल 4c16 '

Answer 5

comD't verListen prepTo adjThose adjOther nouPeople। proYou auxShould advAlways verUse nouPrefixes prepWith proYour adjTable nouNames। proI auxHave adveven verstarted gerUsing proThem prepIn adjNormal nouWriting।

comSee advHow adjEffective proIt verIs? nouPeople auxCan verUnderstand proYour nouWriting adjBetter!

Comments

आइए हम इस चर्चा को चैट में जारी रखते हैं ।

— संपतश्री

Answer 6

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

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

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

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

Comments

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

— बेन वोइगट

@BenVoigt, बहुत सच। लेकिन आप अनिवार्य लिंक को भूल गए ।

— वाइल्डकार्ड

Answer 7

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

सबसे व्यापक रूप से इस्तेमाल किया उपसर्गों में से एक था Tblया tbl, लेकिन फिर मैं था TBLऔर tbl_और यहां तक कि*TableName*_Tbl

विजुअल स्टूडियो से क्वेरी करने और काम करने की कोशिश करने पर, यह सिर्फ नरक है, मैं पहले से तय की गई तालिका का एक पूरा सेट नहीं रखता, tblलेकिन कृपया इसे पूरे डेटाबेस के लिए इस तरह रखें, कम से कम।

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

... दूसरी तरफ मैं सिर्फ यह कहना चाहता था, यदि आप अन्य दृष्टिकोण अपनाते हैं और गैर-उपसर्ग, एकवचन-नाम तालिका के लिए जाते हैं, तो आप भविष्य में एक डेवलपर को खुश करेंगे, और खुशी से ज्यादा महत्वपूर्ण क्या है?

Answer 8

हां, एक उपसर्ग जोड़ना जो ऑब्जेक्ट के प्रकार को दर्शाता है एक समस्या है, और अनावश्यक है । चूंकि,

1. कभी-कभी वस्तुएं जीवन को कुछ के रूप में शुरू करती हैं लेकिन अंत में कुछ और बन जाती हैं । (उदाहरण के लिए तालिका tblXxxमें विभाजित किया गया tblXxxYऔर tblXxxZकिसी कारण से और प्रतिस्थापित एक राय यह है कि दो नए टेबल मिलती है। अब आप एक दृश्य कहा जाता है tblXxx)।
2. जब आप tblसंपादक में टाइप करते हैं, तो इसका AutoComplete फीचर 45 सेकंड के लिए हैंग हो जाता है और फिर आपको 4000 प्रविष्टियों की सूची दिखाता है।

परंतु...

मैं शैतान के वकील की भूमिका निभाने जा रहा हूं और कहता हूं कि कुछ लोगों ने इसके खिलाफ सलाह दी है। कुछ दुर्लभ मामले हैं जो एक प्रत्यय / उपसर्ग उपयोगी हो सकते हैं, और यहां उस संगठन का एक उदाहरण है जिसके लिए मैं काम करता हूं।

हमारे पास ईआरपी सिस्टम आधारित एक इकाई है, जहां व्यापार तर्क ओरेकल पीएल / एसक्यूएल में लिखा गया है। यह लगभग दो दशक पुराना है, फिर भी एक बहुत ही स्थिर प्रणाली है (यह एक विरासत प्रणाली नहीं है। हम इसे लगातार विकसित कर रहे हैं)।

सिस्टम इकाई आधारित है, और प्रत्येक इकाई एक तालिका, कई विचार, कई पीएल / एसक्यूएल पैकेज और अन्य डेटाबेस ऑब्जेक्ट्स के एक मेजबान को जोड़ती है।

अब, हम चाहते हैं कि समान इकाई से संबंधित वस्तुएं समान नाम की हों, लेकिन फिर भी इसका उद्देश्य और प्रकार भिन्न हो। इसलिए, यदि हमारे पास दो संस्थाएँ हैं, जिनका नाम है CustomerOrderऔर CustomerInvoice, हमारे पास निम्नलिखित वस्तुएँ होंगी:

1. डेटा [ TABप्रत्यय] संग्रहीत करने के लिए टेबल्स :
   • CUSTOMER_ORDER_TAB
   • CUSTOMER_INVOICE_TAB।
2. ग्राहकों द्वारा उपयोग किए जाने वाले दृश्य [कोई प्रत्यय]:
   • CUSTOMER_ORDER
   • CUSTOMER_INVOICE।
3. बुनियादी संचालन के लिए इंटरफ़ेस; (पीएल / एसक्यूएल पैकेज) [ APIप्रत्यय]:
   • CUSTOMER_ORDER_API
   • CUSTOMER_INVOICE_API।
4. रिपोर्ट जनरेटर; (पीएल / एसक्यूएल पैकेज) [ RPIप्रत्यय]:
   • CUSTOMER_ORDER_RPI
   • CUSTOMER_INVOICE_RPI।
5. प्राथमिक कुंजी के लिए सूचकांक [ PKप्रत्यय]:
   • CUSTOMER_ORDER_PK
   • CUSTOMER_INVOICE_PK।
6. द्वितीयक सूचकांक [ IXप्रत्यय]:
   • CUSTOMER_ORDER_XXX_IX
   • CUSTOMER_INVOICE_XXX_IX(जहां XXXसूचकांक के उपयोग का वर्णन करता है)।
7. ... और इसी तरह।

यह वास्तव में Apps हंगेरियन का एक रूप है (ध्यान दें कि एक ही प्रकार की वस्तुओं में उद्देश्य के आधार पर अलग-अलग प्रत्यय हो सकते हैं)। लेकिन, उपसर्ग के बजाय एक प्रत्यय के साथ। मैं आपको पर्याप्त नहीं बता सकता कि यह प्रणाली पढ़ना कितना आसान है। IntelliSense वास्तव में काम करता है क्योंकि TBL4000 परिणाम टाइप करने और प्राप्त करने के बजाय , मैं Customerनामित संस्थाओं से संबंधित सभी ऑब्जेक्ट टाइप और प्राप्त कर सकता हूं Customer*।

इसलिए, यहां मैंने आपको दिखाया है कि मेटाडेटा कैसे उपयोगी हो सकता है। इसका उद्देश्य किसी एक नाम से पहचानी जाने वाली डेटाबेस ऑब्जेक्ट का संबंधित सेट है, फिर भी उन्हें उनके उद्देश्य के आधार पर अलग-अलग करना है ।

यह कहने के बाद कि, यदि आपके पास इस प्रकार की प्रणाली नहीं है, तो वस्तु के प्रकार का प्रत्यय या प्रत्यय लगाने का कोई फायदा नहीं है ।

ध्यान दें कि हम जैसे प्रत्यय उपयोग नहीं किया है _table, _packageया _view(यानी प्रकार वस्तु का)। उदाहरण के लिए, दोनों (3) और (4) पीएल / एसक्यूएल पैकेज हैं, फिर भी एक अलग प्रत्यय का उपयोग करें। यह (5) और (6) के लिए समान है, दोनों ही इंडेक्स हैं। इसलिए प्रत्यय प्रकार के बजाय उद्देश्य पर आधारित है ।

Comments

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

— ग्रहामज42

Answer 9

tl; dr इसे (बहुत संभावना है) निरर्थक जानकारी कहते हैं, संज्ञानात्मक उपरि के लिए अग्रणी है, और इसलिए इसे हटा दिया जाना चाहिए।

संदर्भ एक अद्भुत चीज है, खासकर कंप्यूटर सिस्टम में। संदर्भ के बाहर आप संभवतः यह नहीं बता सकते हैं कि कुछ कहा जाता usersहै एक मेज, एक दृश्य, एक संग्रहीत प्रक्रिया या पूरी तरह से कुछ और। विरासत (या बस बुरी तरह से लिखी गई) प्रणाली और भाषाएं अक्सर कोड को पढ़ते समय संदर्भ को बाहर करना मुश्किल बनाती हैं। उदाहरण के लिए, बैश में, आप यह नहीं बता सकते कि कम से कम फ़ंक्शन की सामग्री को पढ़े function usersबिना क्या होता है । जावा में, बहुत पारदर्शी है, और आप आसानी से विवरण खोद सकते हैं।Map<Uid,UserDetails> users()

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

Answer 10

एक रिलेशनल डेटाबेस मैनेजमेंट सिस्टम की विशेषताओं में से एक यह है कि यह ग्राहकों को भौतिक संग्रहण से जानकारी की तार्किक प्रस्तुति को अलग करता है। पूर्व एक पंक्ति में स्तंभ है। उत्तरार्द्ध एक स्टोरेज वॉल्यूम पर फ़ाइलों के रूप में है। एक के बाद एक मानचित्र बनाना डीबीएमएस का काम है। यह केवल DBA या sysadmin के लिए एक चिंता का विषय है जो हार्डवेयर जानकारी की जरूरत का समर्थन कर रहा है। उपभोक्ता को वास्तव में उन चिंताओं से अवगत नहीं होना चाहिए।

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

उनके कार्यान्वयन प्रकार के साथ कलाकृतियों के नामों को उपसर्ग करने से इस प्रकार की चिंताओं को अलग किया जाता है। क्लाइंट अब सर्वर के इनरल्स पर निर्भर है और निर्भर है। सर्वर के कोडिंग में बदलाव से क्लाइंट को फिर से काम करना पड़ सकता है।

Answer 11

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

---

SELECT
  bar
  , fizz
  , buzz
FROM dbo.foo

उपर्युक्त कथन में मैं नाम की किसी चीज़ से तीन कॉलम चुन रहा हूँ dbo.foo। उपसर्गों की मुख्य शिकायतों में से एक यह है कि उन्हें पता नहीं है कि क्या dbo.fooएक तालिका या एक दृश्य है। बेशक यह एक अमूर्त के रूप में एक दृश्य की ताकत में से एक है, लेकिन मैं पचाता हूं। वे कहते हैं कि हमें वस्तु को इस तरह उपसर्ग करना चाहिए dbo.tblFoo। अब वे देख सकते हैं कि उपरोक्त क्वेरी में ऑब्जेक्ट एक टेबल (शायद) है। हालाँकि अगर हम उस लक्ष्य के कार्यात्मक समकक्ष लिखते हैं तो यह इस तरह दिखेगा।

SELECT
  bar
  , fizz
  , buzz
FROM dbo.Foo --table

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

SELECT
  qc.occurances
  , i.employeeId
  , q.questionText
FROM dbo.questionCount /*Indexed view*/ qc WITH (NOEXPAND)
  INNER JOIN dbo.interviewer /*partitioned view*/ i ON i.employeeId = qc.interviewerId
  INNER JOIN dbo.question /*table*/ q ON q.id = qc.questionId
WHERE
  EXISTS (
           SELECT 
             1 
           FROM dbo.currentEmployees /*view*/ ce 
             INNER JOIN dbo.questionsAsked /*table*/ qa ON qa.candidateId = ce.candidateId
           WHERE
             ce.employeeId = i.employeeId
             AND
             qa.questionId = q.id
         )
  AND
  qc.occurances > 5;

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

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

Answer 12

यह कई बार कवर किया गया है, लेकिन शायद एक अमेरिकी एसक्यूएल और रिलेशनल डेटाबेस विशेषज्ञ जो सेल्को द्वारा सबसे प्रसिद्ध है । मैं व्यक्तिगत रूप से ऑनलाइन अपने दोषारोपण में से एक की प्राप्ति अंत पर किया गया है (महसूस किया सम्मानित), और वह "tibbling", या सरल शब्दों के रूप में "वर्णित के रूप में इन उपसर्गों बारे में बात करती skeuomorphism "।

सामान्य विचार यह है कि ये उपसर्ग बहुत पहले से एक कोडिंग अभ्यास है (शायद नामकरण सीमाओं के कारण, ऑब्जेक्ट नामों के लिए 8 बाइट सीमा की तरह), प्रोग्रामर की पीढ़ियों को बिना किसी उपयोगी कारण के पारित कर दिया, इसके अलावा अन्य सिर्फ "जिस तरह से" है। यह किया जाता है"।

कंपनियां, ब्लॉगर और प्रोग्रामर कोडिंग की अपनी शैली के साथ जानकारी पर गुजरते हैं, और कुछ शैलियों दूसरों के लिए "फ्रेंकस्टीन" थोड़ी अधिक हो सकती हैं। एक कंपनी में "हाउस स्टाइल" हो सकता है, और प्रोग्रामर को इस अभ्यास को सीखने के लिए मजबूर किया जाता है।

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

राउंड अप करने के लिए: यह किसी भी मूल्य को नहीं जोड़ता है, यह प्रत्येक टेबल के नाम पर स्टोरेज स्पेस के बिल्कुल 4 बाइट जोड़ता है, क्योंकि इसके अलावा कोई कारण नहीं है। यह आधुनिक SQL सर्वर सिस्टम के लिए कुछ भी नहीं प्रदान करता है, लेकिन अगर यह आपको वहां होने से बेहतर महसूस कराता है, तो आगे बढ़ें और इसका उपयोग करें।

Comments

मैंने लाइन के कारण इस उत्तर को अस्वीकार कर दिया, "लेकिन अगर इससे आपको वहां होने में बेहतर महसूस होता है, तो आगे बढ़ें और इसका उपयोग करें।" यह एक सम्मेलन का उपयोग करने के लिए एक भयानक कारण है।

— jpmc26

@ jpmc26 मैं सहमत हूँ कि यह फिर भी एक कारण है, और वह इसका उपयोग करने के लिए स्वतंत्र है।

— जॉन बेल

@ जॉनबेल, लेकिन आप इसकी सिफारिश नहीं करने के लिए स्वतंत्र हैं ...

— dan1111

@ dan1111 मैं वास्तव में हूं, और मुझे लगता है कि मेरे उत्तर के सामान्य स्वर से, किसी को भी कुछ तार्किक तर्क के साथ - जो मुझे आशा है कि उन्हें किसी भी प्रोग्रामिंग भाषा का उपयोग करना चाहिए, यह कटौती करने में सक्षम होगा कि "tbl_" या "का उपयोग करने की अनुशंसा नहीं की जाती है" _tbl "।

— जॉन बेल

Answer 13

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

Comments

मुझे यकीन नहीं है कि 'आपको तुरंत ऐसा करना बंद कर देना चाहिए, लेकिन आप इसे अलग स्थान पर करना जारी रख सकते हैं' कोई मतलब नहीं है।

— अंडरस्कोर_ड

Answer 14

"क्या वास्तव में एक समस्या है" टेबल के साथ अपनी तालिका को उपसर्ग न करें "?

प्रणाली के बारे में? नहीं। अन्य लोगों के बारे में? शायद। आप लोटा घृणा उत्पन्न कर सकते हैं।

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

Answer 15

मेरा कहना है कि कृपया ऐसा करना बंद करें। यह अतीत में हुआ है, लेकिन इसे जारी रखने से आप नए लोगों को प्रोत्साहित करते हैं जो आपके पर्यावरण में आने के लिए सोचते हैं कि यह एक स्थानीय सम्मेलन है और जारी है। लेकिन वे सिर्फ जारी नहीं रखेंगे, वे इसे थोड़ा अलग तरीके से करेंगे

जब किसी विशिष्ट वस्तु के लिए एक db को पीछे छोड़ते हुए, और मैं केवल वह नहीं हूं जो ऑब्जेक्ट एक्सप्लोरर खोलेगा और मुझे लगता है कि मैं इसे स्क्रॉल करूंगा, तो आप जानते हैं कि यह वर्णानुक्रमिक है। जब तक कि उपसर्ग पानी को मैला करने लगते हैं, और मेरे पास tblname, tbl_name, tbname, t_name और एक हजार अन्य विविधताएं हैं, यह वास्तव में उस तालिका को खोजने के लिए कठिन हो जाता है जिसे आप जानते हैं कि पहले से ही एक तालिका है

इसी तरह सब कुछ vw_ या sp_ को प्रीफ़िक्स करते हुए, कोई व्यक्ति आएगा और आपको SPname, spname, s_p_name मिलेगा। सभी उपसर्गों को हटा दें, सॉफ़्टवेयर जानता है कि आइटम क्या है, अगर आपको वास्तव में जानने की आवश्यकता है, तो इसके बजाय एक प्रत्यय का उपयोग करें। NameOfMyView_v, NameOfMyProc_sp। नेत्रहीन खोज करने के लिए बहुत आसान है

लेकिन क्या होगा यदि आप एक लंबे संग्रहीत संग्रह के माध्यम से फंस रहे हैं और आसानी से नहीं बता सकते हैं कि एक दृश्य एक खरीद या तालिका क्या है? अच्छी तरह से संभावना है कि ये वैसे भी अलियास हो जाएंगे, और भले ही प्रत्यय आपके बचाव में न आए

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

Answer 16

यदि मुझे उपसर्ग 'tbl' होने के एक लाभ के बारे में सोचना है, तो यह है कि वर्तमान SSMS में, intellisense के साथ, मैं सिर्फ टाइप कर सकता हूं

select * from tbl

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

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

मुझे याद है कि sql सर्वर 2005 के दिनों में, यह पता लगाने की आवश्यकता थी कि कौन सी तालिकाओं का उपयोग किया जाता है जिसमें संग्रहीत कार्यविधियाँ / दृश्य होते हैं, तालिका नामों के साथ उपसर्ग, यह रेगुलर एक्सप्रेशन / C # के साथ ऐसा आसान काम था। (हां, मुझे पता है कि अन्य तरीके भी थे, यहां कोई तर्क नहीं)।

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

Comments

SSMS में ऑब्जेक्ट मैनेजर को खोलना बहुत आसान है, यह देखने के लिए कि सभी टेबल नामों को "फायदा" है। इसके अलावा मुझे पूरा यकीन है कि आपकी ट्रिक केवल स्कीमा के बिना तालिका को संदर्भित करते समय ठीक से काम करेगी जिससे अन्य समस्याएं हो सकती हैं। मुझे नहीं पता कि इन या अन्य कारणों ने डाउन-वोट के लिए लोगों के निर्णय को प्रभावित किया है लेकिन वे मेरी राय में डाउन-वोट करने के लिए उद्देश्य कारणों की तरह लगते हैं।

— एरिक

मुझे यह कहना है कि "tbl" उपसर्ग का उपयोग करने से मेरी आँखों में इसका सर्वोच्च लाभ होता है, हाँ, आप इंटेलीजेंस को ट्रिगर करने के लिए स्कीमा टाइप कर सकते हैं, लेकिन यदि मेरे परीक्षण वातावरण में, मेरे पास मेरा स्कीमा के रूप में [dbo] है? दरअसल, अपने स्वयं के प्रोजेक्ट में, मैं अक्सर अंडरस्कोर "_" का उपयोग करना पसंद करता हूं (लेकिन यह सिद्धांत में "टीबीएल" के समान है)। हर चीज के सिक्के के रूप में दो पहलू होते हैं, जैसे कुछ लोग लंबी तालिका के नाम पसंद करते हैं जबकि अन्य संक्षिप्त रूप से पसंद करते हैं। यह उपसर्ग प्रश्न बहुत सारी दिलचस्प चर्चा को सामने लाता है। मेरी राय है कि जब तक आपका तर्क समझ में आता है, यह एक अच्छा तर्क है।

— जियो

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

— एंड्री एम

Answer 17

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

ऐसा कुछ है जो मैंने किसी भी अन्य उत्तर में नहीं देखा है, लेकिन मैं एक डेवलपर-सह-डीबीए हूं, इसलिए शायद अन्य लोगों को विरासत कोड पर काम नहीं करना पड़ा, जहां प्रश्न एप्लिकेशन में एम्बेड किए जा सकते हैं, और सभी नहीं प्रश्न स्कीमा, और इस तरह की चीजों के साथ संदर्भ को पूरी तरह से योग्य बनाते हैं। (यहां तक कि अगर सब कुछ पूरी तरह से योग्य है, तो आप खोजने की जरूरत है dbo.Userऔर [dbo].[User]और dbo.[User]और इतने पर)। या डेटाबेस संस्करण जहां "निर्भरता की जानकारी" बासी हो जाती है और गलत है (उदाहरण के लिए MS-SQL के पुराने संस्करण)

इसलिए, मैंने जिन कुछ परियोजनाओं पर काम किया है, उन्हें इस तरह मिलाया जाता है, मैंने एक tया vउपसर्ग (tbl_ मूर्खतापूर्ण) प्राप्त किया, बस इसे और अधिक चयनात्मक खोज शब्द बनाने के लिए।

बाद के प्रोजेक्ट्स में, SQL सर्वर डेटा टूल्स (हेल्लो, फाइंड ऑल रेफरेंस) जैसी चीजों के साथ, और डेटाबेस का उपयोग विशेष रूप से ORM लेयर के माध्यम से किया जाता है, कोई उपयोगिता नहीं है, क्योंकि टेबल के सभी उपयोगों को ढूंढना तुच्छ है (जैसा कि इसका नाम बदल रहा है!)।

Comments

आइए हम इस चर्चा को चैट में जारी रखते हैं ।

— मार्क सोउल

Answer 18

प्रत्येक पक्ष के अपने फायदे और इसके नुकसान हैं। यह सिर्फ आपकी टीम या कंपनी के नेतृत्व पर निर्भर है कि वह सम्मेलनों का पालन करने का निर्णय ले।

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

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

अंत में यह वास्तव में उबलता है कि आपकी टीम क्या पसंद करती है और यह कोड / स्क्रिप्ट कैसे लिखती है।

Comments

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

— केविन वी।

Answer 19

मेरे पास "tbl" के साथ तालिका नामों को उपसर्ग करने का एक कारण था। यदि आप डेटाबेस ऑब्जेक्ट की सूची देख रहे हैं, तो आप इस क्वेरी को चला सकते हैं:

select * from sysobjects

यदि आप केवल टेबल प्राप्त करना चाहते हैं, तो आप यह कर सकते हैं:

select * from sysobjects where type = 'U'

कौन याद कर सकता है? यदि आपकी तालिका के सभी नाम "tbl" से शुरू होते हैं, तो आप इस क्वेरी का उपयोग कर सकते हैं जिसके लिए आपको कॉलम के मानों को याद रखने की आवश्यकता नहीं है:

select * from sysobjects where name like 'tbl%'

---

चूँकि आपने SQL सर्वर 2014 को टैग किया है, इसलिए यह आपके लिए लागू नहीं होता है क्योंकि SQL Server 2005 के अनुसार, आप इसके बजाय ऐसा कर सकते हैं:

select * from sys.tables

मैं तालिका नामों को उपसर्ग करने का एक और कारण नहीं सोच सकता।

Comments

1) पुन: " कौन याद कर सकता है? " याद रखना where type = 'U'बहुत अलग नहीं है where name like 'tbl%', खासकर जब आप इसे कुछ बार करते हैं। 2) सही जानकारी होने के हित में, sys.tables: SQL सर्वर 2005 में शुरू उपलब्ध था technet.microsoft.com/sr-latn-rs/library/ms187406(v=sql.90) technet.microsoft.com/sr-latn- rs / पुस्तकालय / ms187406 (v = sql.90)

— सोलोमन रुट्ज़की

आपको याद नहीं होगा 'U'लेकिन आप हमेशा एक दृश्य बना सकते हैं: create view all_the_tables as select * from sysobjects where type = 'U';तो बस चलाएंselect * from all_the_tables;

— ypercube