किसी डेटाबेस में स्तंभों को लेबल करने का एक प्रभावी तरीका क्या है?

Question

मैंने अपने डेटाबेस में कॉलम को इस तरह लेबल किया:

user_id
user_name
user_password_hash

दो तालिकाओं में शामिल होने के दौरान संघर्ष से बचने के लिए, लेकिन फिर मैंने कुछ और कैसे उर्फ ​​तालिकाओं के बारे में सीखा, और मैंने ऐसा करना बंद कर दिया।

किसी डेटाबेस में स्तंभों को लेबल करने का एक प्रभावी तरीका क्या है? क्यूं कर?

Comments

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

— जो

@ जो, खैर, मैंने हमेशा MySQL और SQLite3 का उपयोग किया है, लेकिन यह अधिकांश अन्य डेटाबेस पर लागू होना चाहिए।

— थॉमस ओ

@ जो ने कभी नहीं देखा कि ओरेकल अलग है। क्या आप एक लिंक दे सकते हैं?

— bernd_k

@bernd_k: मैंने अपने जवाब में कुछ लिंक जोड़े हैं , नीचे

— जो

Answer 1

आपके मामले में, उपसर्ग उपयोगकर्ता निरर्थक है। हम (देव प्रभारी) जानते हैं कि यह तालिका उपयोगकर्ता है, इसलिए user_हर क्षेत्र के सामने उपसर्ग क्यों जोड़ें ?

जो मैं आपको सुझाव दूंगा वह यह है कि इसे और अधिक प्राकृतिक दृष्टिकोण के साथ करें।

किसी व्यक्ति की विशेषताएं क्या हैं: अंतिम नाम, पहला नाम, जन्मतिथि, राष्ट्रीयता, आदि ...

एक कार की विशेषताएं क्या हैं: मॉडल, वर्ष, रंग, ऊर्जा, आदि ...

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

Comments

हां, यह मुझे प्रभावित करता है जब लोग ऐसा करते हैं। इसके अलावा जब वे अपने सभी टेबल tbl_whatever को कॉल करते हैं।

— गयूस

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

— परिसीमन

Answer 2

Spredzy की टिप्पणी के अलावा, अपनी प्राथमिक कुंजियों को समान (ID) लेबल करें ताकि जब आप मक्खी पर प्रश्न लिख रहे हों, तो आप आसानी से याद कर सकें (u.ID = c.ID) बजाय देखने के लिए "क्या यह देश था , देश_आईडी, कंट्री_आईडी, कंट्रीआईडी? "

Comments

मैंने एक बार एक डेटाबेस पर काम किया था जहाँ डीबीए ने कुछ तालिकाओं और आईडी में दूसरों का उपयोग करने का निर्णय लिया था और हमने MySQL को संवेदनशील होने के लिए सेट किया था ... मजेदार समय!

— तोबी

हम आमतौर पर tablename.tablename_id का उपयोग करते हैं। जैसे कार .car_id; person.person_id। तालिकाओं के लिए एकवचन नाम।

— ग्लासस

@glasnt स्मार्ट निर्णय।

— गारिक

यह वास्तव में एक बहुत बुरा विचार है, और आप एसक्यूएल USINGक्लॉज (यह कल्पना के खिलाफ है) का उपयोग करने की क्षमता खो देंगे ।

— इवान कैरोल

Answer 3

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

जब आपके पास user.id और Cars.id हो सकते हैं, तो user.user_id और cars.car_id वाले कोई अर्थ नहीं

Answer 4

मेरा तर्क है कि एक डेटाबेस स्कीमा में, प्रत्येक कॉलम में तालिकाओं में एक अद्वितीय नाम होना चाहिए। इसके कई कारण हैं:

• मॉडलिंग के दृष्टिकोण से: आप विशेषताओं के एक सूप से शुरू करते हैं और आप इसे तालिकाओं में सामान्य करते हैं। समय के साथ, आप आगे या सामान्य हो सकते हैं या विचारों या भौतिक विचारों को पेश कर सकते हैं या नई तालिकाओं को प्रस्तुत कर सकते हैं। यह कभी कोई समस्या नहीं है यदि सभी स्तंभ नाम अद्वितीय हैं।

• आप इस वाक्य रचना में शामिल होने का उपयोग कर सकते हैं: a JOIN b USING (a_id) JOIN c USING (a_id)। बहुत सुविधाजनक है और निम्न बिंदु के साथ भी मदद करता है।

• यदि आप बहुत सारे जुड़ावों के साथ क्वेरीज़ चलाते हैं या भौतिक विचारों को बनाते हैं SELECT *, तो आप कभी भी (संघर्ष, शायद ही कभी) संघर्ष करेंगे। में शामिल होने के बारे में सोचो person.name, product.name, country.name, आदि Urgh।

• सामान्य तौर पर, यदि आपके पास बड़े प्रश्न हैं, तो idहर जगह का क्या अर्थ है, इस पर नज़र रखना मुश्किल है।

Comments

उदाहरण के लिए आप कर्मचारी के नाम और साइट के नाम के लिए कॉलम का नाम कैसे देंगे? आप नाम लेबल कॉलम के अतिरेक से कैसे बचेंगे?

— २३:२१ पर Spredzy

@Spredzy: मैं सिर्फ अतिरेक के साथ जाना होगा।

— पीटर आइजेंट्रूट

इन चिंताओं का जवाब: उपनाम।

— जॉन ऑफ ऑल ट्रेड्स

Answer 5

आइए देखें, आपके उदाहरण से यह कुछ इस तरह दिखाई देगा:

USERS
----
id
username,
password
registration_date

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

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

Comments

+1 के लिए "कुछ शैली आपको पसंद है और उसके साथ रहें।" निरंतरता किसी विशेष मानक के अनुपालन की तुलना में बेहतर है (हालांकि यदि आपने अभी तक एक मानक नहीं चुना है, तो कुछ दूसरों की तुलना में बेहतर हैं)।

— जॉन ऑफ ऑल ट्रेड्स

Answer 6

दूसरों की तरह, मेरा सुझाव है कि आप स्तंभ के भाग के रूप में तालिका का नाम शामिल नहीं करें। जब तक कि आपको सभी समान कॉलम नामों के साथ सैकड़ों टेबल न मिलें: यदि आपके पास आईडी नामक कॉलम के साथ सभी दर्जनों टेबल हैं, तो हर तरह से टेबल नाम के साथ उन्हें उपसर्ग करें।

मैंने हाल ही में एक कंपनी छोड़ी है, जहां डेवलपर्स में से एक ने पीके और एफके के साथ प्राथमिक कुंजी और विदेशी कुंजी कॉलम को उपसर्ग करना पसंद किया है। इससे कुछ एबॉमिनेशन होते हैं, जहां कॉलम pkfk से शुरू होते हैं (आमतौर पर 2 कॉलम के आधार पर एक कंपोजिट प्राइमरी की, जिसमें एक कॉलम दूसरी टेबल की विदेशी कुंजी होती थी)।

Comments

कि एक fk_cluster के रूप में गिनती करता है?

— काजी

Answer 7

मैं एक ऐसे वातावरण में काम कर रहा हूं, जहां प्रत्येक स्तंभ का नाम तालिका के नाम से उपसर्ग के साथ शुरू होता है, यह मेरा आविष्कार नहीं है, लेकिन मैं इससे काफी खुश हूं।

डेटाबेस में सभी टेबलों पर आदर्श रूप से कॉलम नाम अद्वितीय हैं।

कुछ अवलोकन:

• हमें केवल टेबल अलायस की जरूरत होती है, जब टेबल एक चुनिंदा स्टेटमेंट में कई बार शामिल होते हैं
• कोड स्निपेट की नकल करते समय यह कुछ दोषों को रोकता है, क्योंकि स्तंभ नामों को तालिका नाम के अनुकूल होना चाहिए
• यह किस तालिका को एक विदेशी कुंजी स्तंभ बिंदुओं को दिखाने में मदद करता है

सामान्य विचार: सबसे महत्वपूर्ण प्रत्येक नामकरण सम्मेलनों की स्थिरता है: - एकवचन बनाम बहुवचन (ठीक है जो तालिकाओं पर लागू होता है और कॉलम नहीं) - प्राथमिक और विदेशी कुंजी की पहचान करें (वे डेटाबेस की सामग्री बनाम संरचना का निर्माण करते हैं) - जब संगत हों आप एक ही तार के तार और छोटे संस्करण को स्टोर करते हैं - झंडे, स्थिति आदि के अनुरूप हो।

Answer 8

मैं स्प्रेडज़ी के उत्तर से सहमत हूं, लेकिन यह जोड़ूंगा कि प्राथमिकता के मामले में मैं अंडर_स्कोर के बजाय कैमलकेस का उपयोग करूंगा।

पहला नाम, अंतिम नाम आदि।

Comments

-1 क्योंकि CamelCase सभी डेटाबेस सिस्टम में काम नहीं करता है और आपने डेटाबेस सिस्टम को निर्दिष्ट नहीं किया है। उदाहरण के लिए, Oracle में CamelCase का उपयोग करने के लिए इसकी बुरी खबर (इसे बनाने के लिए दोहरे उद्धरण चिह्नों का उपयोग करना होगा लेकिन तब से, इसे एक्सेस करने वाले सभी लोगों को इसे उपयोग / उपयोग करने के लिए हुप्स के माध्यम से कूदना होगा)। कितना बुरा सपना।

— स्कॉटिश

@ScottCher - मुझे नहीं पता था कि यह ओरेकल में काम नहीं करता है, लेकिन फिर मैं ओरेकल डीबीए नहीं हूं। मुझे लगता है कि इसे एक दिया जाएगा क्योंकि कॉलम नाम को पहले DBS द्वारा निर्धारित नियमों के अनुपालन की जरूरत है।

— टॉबी

Answer 9

ओरेकल के मामले में, आप कॉलम 'आईडी' या 'नाम' या कुछ भी सामान्य नहीं रखना चाहेंगे ।

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

लेकिन भले ही आप नहीं हैं ओरेकल का उपयोग कर , कई तालिकाओं में दिखाई देने वाले नामों को न काटकर, इसका मतलब यह भी है कि आपको तब हर बार अलियासिंग की परेशानी से गुजरना नहीं पड़ता है जब आपको दो तालिकाओं में चयन करना होता है:

SELECT
  instrument.name as instrument_name,
  instrument.abbr as instrument_abbr,
  source.name     as source_name,
  source.abbr     as source_abbr,
  ...
FROM ...

इसलिए, यदि मल्टी-टेबल चयन आदर्श हैं, तो लंबे कॉलम नाम आपको टाइप करने से बचाते हैं। (यदि आप एक समय में केवल एक तालिका का उपयोग कर रहे हैं ... तो क्या आपको वास्तव में एक रिलेशनल डेटाबेस की भी आवश्यकता है?

... और टाइपिंग की बचत हमें ओरेकल में एक और मुद्दे पर लाती है - कम से कम 8i में (वर्तमान संस्करण जब मैंने ओरेकल एसक्यूएल ट्यूनिंग और डेटा मॉडलिंग पाठ्यक्रम लिया) निष्पादन योजनाओं की कैशिंग केवल पहले इतने सारे वर्णों पर आधारित है क्वेरी (सटीक मान याद नहीं कर सकता ... 1024?), इसलिए यदि आपके पास ऐसे प्रश्न हैं, जो केवल उस खंड के अंत में सभी तरह से भिन्न होते हैं, और आपके द्वारा निकाले जा रहे स्तंभों की वास्तव में लंबी सूची है, तो आप निष्पादन हिट में भाग सकता है क्योंकि यह निष्पादन योजना को सही ढंग से कैश नहीं कर सकता है।

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

...

चूंकि चीजें इसके अलावा हैं:

• कॉलम हमेशा एकवचन होते हैं (टेबल हमेशा बहुवचन होते हैं)
• सभी नाम लोअर केस हैं, बस केस में कुछ केस-सेंसिटिव है
• उपरोक्त के परिणामस्वरूप, ऊंट मामले के बजाय अंडरस्कोर का उपयोग करें।

अद्यतन : उन लोगों के लिए जो ओरेकल के व्यवहार से परिचित नहीं हैं, ओरेकल एसक्यूएल पर अंतिम उदाहरण देखें : शर्तों में शामिल हों , जहां यह उल्लेख है:

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

'पुरानी ज्वाइन सिंटैक्स' (8i और उससे पहले) के तहत, 'NATURAL JOIN' डिफॉल्ट जॉइन व्यवहार था, और मेरा मानना ​​है कि यह तब भी है जब आप एक जॉइन कंडीशन को निर्दिष्ट नहीं करते हैं। एक बार 'नैचुरल जॉइन' 9i में एक आधिकारिक विकल्प था, सामान्य अनुशंसा का उपयोग नहीं किया गया था , क्योंकि खराब कॉलम नामकरण आपको खराब कर सकता है, जो कि मैं अपने अच्छे कॉलम नामों की वकालत कर रहा हूं।

Comments

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

— ScottCher

प्राकृतिक जोइन डिफ़ॉल्ट कभी नहीं रहा। यदि कोई स्पष्ट जुड़ाव नहीं है / दिया गया था, तो एक कार्टेशियन जॉइन किया जाएगा (यानी टेबल में प्रत्येक और प्रत्येक पंक्ति दूसरी तालिका में प्रत्येक पंक्ति में शामिल हो गई है)। ANSI जॉइन करने से पहले सपोर्ट किया जा रहा है (यानी FROM क्लॉज में निर्दिष्ट) जॉइन को WHERE क्लॉज में किया जाना था।

— गैरी

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

— जॉन ऑफ ऑल ट्रेड्स

@ScottCher: "यह तय करने के लिए डेटाबेस तक छोड़ना" - पहला, संभवतः आप "डेटाबेस" के बजाय "DBMS" का मतलब है। दूसरा, ओरेकल में कोई एआई या एन्थ्रोपोमोर्फिस्टिक तंत्र नहीं है; बल्कि, NATURAL JOINनियतात्मक है।

— onedaywhen

@ जो cross joinहै, है और हमेशा 'डिफ़ॉल्ट' रहेगा। जब तक स्पष्ट रूप से उपयोग नहीं किया गया था, ओरेकल स्तंभ नाम पर मेल नहीं खाता natural joinहै

— जैक डगलस

Answer 10

1. कभी भी दोहरे उद्धरण चिह्नों का उपयोग न करें "क्योंकि ऐसा करने पर, आप डेटाबेस के मूल केस-फोल्डिंग को ओवरराइड करते हैं। SQL युक्ति मांग करता है कि सभी पहचानकर्ताओं को ऊपरी मामले में जोड़ दिया जाए। कुछ डेटाबेस, जैसे PostgreSQL उन्हें निचले मामले में मोड़ते हैं। यदि कुछ भी उद्धृत नहीं किया गया है, तो यह सभी डेटाबेस में काम करेगा और वे उन्हें युक्ति या rdbms- विशिष्ट डिफ़ॉल्ट में बदल सकते हैं।
2. एक अंडर_स्कोर ( _) का उपयोग करें , क्योंकि ऊपर के अनुसार - आपको कैमलकेस का उपयोग नहीं करना चाहिए।

3. {entity}_idआईडी के लिए उपयोग (और उन आईडी को इंगित करने वाली विदेशी कुंजी)। क्योंकि तब आप USINGक्लॉज का उपयोग कर सकते हैं । ज्वाइन-कंडीशन्स में उपयोग किए जाने वाले विश्व स्तर पर विशिष्ट कुंजी नाम कल्पना में स्थापित एक सम्मेलन है।

   SELECT *
   FROM employee
   INNER JOIN department
     USING (department_id);
   
     -- compare to
     ON employee.department_id = department.department_id;

Comments

मैंने इसे अधिक स्पष्ट होने के लिए अद्यतन किया।

— इवान कैरोल