प्राथमिक कुंजी / विदेशी कुंजी नामकरण सम्मेलन [बंद]

Question

हमारे देव समूह में हमारे पास प्राथमिक और विदेशी कुंजी के नामकरण सम्मेलन के बारे में एक उग्र बहस है। हमारे समूह में मूल रूप से विचार के दो स्कूल हैं:

1:

Primary Table (Employee)   
Primary Key is called ID

Foreign table (Event)  
Foreign key is called EmployeeID

या

2:

Primary Table (Employee)  
Primary Key is called EmployeeID

Foreign table (Event)  
Foreign key is called EmployeeID

मैं किसी भी कॉलम में तालिका के नाम की नकल नहीं करना चाहता (इसलिए मैं ऊपर दिए गए विकल्प 1 को पसंद करता हूं)। वैचारिक रूप से, यह कई अन्य भाषाओं में अनुशंसित प्रथाओं के अनुरूप है, जहां आप इसके संपत्ति के नाम में ऑब्जेक्ट के नाम का उपयोग नहीं करते हैं। मुझे लगता है कि विदेशी कुंजी का नामकरण EmployeeID(या Employee_IDबेहतर हो सकता है) पाठक को बताता है कि यह तालिका IDका कॉलम है Employee।

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

इसके अलावा, मुझे लगता है कि स्तंभ नाम में तालिका का नाम होना अतिरेक है, क्योंकि यदि आप तालिका को एक इकाई के रूप में और उस इकाई की संपत्ति या विशेषता के रूप में एक स्तंभ के बारे में सोचते हैं, तो आप इसे आईडी विशेषता के रूप में मानते हैं Employee, नहीं EmployeeIDएक कर्मचारी की विशेषता। मैं नहीं जाते एक मेरे सहकर्मी क्या उसके पूछने PersonAgeया PersonGenderहै। मैं उससे पूछता हूं कि उसकी उम्र क्या है।

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

Comments

सवाल यह डुप्लिकेट stackoverflow.com/questions/208580/...

— माइक Henke

मैंने 10 से अधिक इसी तरह के प्रश्न पढ़े और अंत में पाया कि शीर्ष 3 उत्तर यहां अच्छे हैं: stackoverflow.com/a/465146/781695

— उपयोगकर्ता

बस एक साइड नोट: च्वाइस 2 आपको 'नेचुरल जॉइन' की अनुमति देगा। हेक, अभी भी 'Employee.ID as EmployeeID' जोड़कर इसे पसंद 1 में क्यों नहीं किया गया। लेकिन बेहतर अभ्यास तरीका 'ON Employee.ID = Event.EmployeeID' का उपयोग करके 'जॉइन' करना प्रतीत होता है।

— सिंह

दोनों स्थितियों में आप एक या अधिक रानियों में उपनाम (या 'table_name.column_name') का उपयोग कर रहे हैं क्योंकि आप दोनों ही मामलों में स्तंभ नामों को दोहरा रहे हैं।

— Please_Dont_Bully_Me_SO_Lords

Answer 1

यह वास्तव में कोई फर्क नहीं पड़ता। मैंने कभी ऐसी प्रणाली में भाग नहीं लिया है जहाँ विकल्प 1 और विकल्प 2 के बीच वास्तविक अंतर है।

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

एक को चुनें और उन्हें उन मुद्दों पर ध्यान केंद्रित करने के लिए कहें जो वास्तव में आपके कोड को प्रभावित करते हैं।

संपादित करें: यदि आप मज़े करना चाहते हैं, तो उन्हें लंबाई में निर्दिष्ट करें कि उनका तरीका पुनरावर्ती तालिका संदर्भों के लिए बेहतर क्यों है।

Comments

+1, सामान्य ज्ञान के लिए ... इसके बारे में बहस करने के लिए और अधिक महत्वपूर्ण बातें हैं .. तो, क्या यह मेरा तरीका है (पसंद 2)

— चार्ल्स ब्रेटाना

और, स्व-संदर्भित DRI के लिए, जब एक से अधिक FK होते हैं जो एक ही PK को सेल्फ-रेफर करते हैं, तो आपको दोनों "मानकों" का उल्लंघन करना होगा, क्योंकि दो FK कॉलम को एक ही नाम नहीं दिया जा सकता है ... उदाहरण के लिए, EmployeeTable EmployeeId PK, SupervisorId FK, MentorId Fk, PartnersId FK, आदि आदि के साथ ...

— चार्ल्स Bretana

Answer 2

यदि दोनों स्तंभों में दोनों तालिकाओं (कन्वेंशन # 2) में एक ही नाम है, तो आप कुछ टाइपिंग और कुछ बॉयलरप्लेट के शोर को बचाने के लिए SQL में USING सिंटैक्स का उपयोग कर सकते हैं:

SELECT name, address, amount
  FROM employees JOIN payroll USING (employee_id)

कन्वेंशन # 2 के पक्ष में एक और तर्क यह है कि जिस तरह से रिलेशनल मॉडल तैयार किया गया था।

प्रत्येक कॉलम का महत्व आंशिक रूप से संबंधित डोमेन के नाम के साथ लेबल करके व्यक्त किया जाता है।

Comments

SQL सिंटैक्स और शब्दार्थ वास्तव में एक बहुत अच्छा सुराग देते हैं कि इसका उपयोग कैसे किया जाना चाहिए। जैसे USING सिंटैक्स का अर्थ है कि एक ही डोमेन वाले कॉलम का एक ही नाम होना चाहिए, NULL = NULL -> NULL का अर्थ है NULL का अर्थ "लागू नहीं" के बजाय "अज्ञात" है, और ONDDATE CASCADE का अर्थ है कि कुंजी को केवल अद्वितीय होना चाहिए, अपरिवर्तनीय नहीं।

— स्टीवन हुविग

इससे भी बेहतर, यह इसकी अनुमति देता है SELECT name, address, amount FROM employees NATURAL JOIN payroll:।

— onedaywhen

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

— स्टीवन हुआविग

+1 लेकिन हमेशा एक अपवाद होता है। उदाहरण के लिए, यदि आपके पास पेरोल में दो कॉलम हैं जो दोनों विदेशी कर्मचारी हैं (एक व्यक्ति को भुगतान किया जा रहा है, तो बजट प्राधिकारी के साथ प्रबंधक, उदाहरण के लिए दूसरा संदर्भ)। लेकिन हम दोनों विदेशी चाबियों को नाम नहीं दे सकते employee_id।

— बिल करविन

"कीवर्ड" का उपयोग MySql विशिष्ट है। टी-एसक्यूएल में काम नहीं करता है-दुर्भाग्य से।

— बर्डस

Answer 3

मुझे लगता है कि यह आप पर निर्भर करता है कि आप किस तरह से आवेदन करते हैं। यदि आप ORM का उपयोग करते हैं या वस्तुओं का प्रतिनिधित्व करने के लिए अपनी तालिकाओं को डिज़ाइन करते हैं तो विकल्प 1 आपके लिए हो सकता है।

मुझे डेटाबेस को अपनी परत के रूप में कोड करना पसंद है। मैं सब कुछ नियंत्रित करता हूं और ऐप केवल संग्रहीत प्रक्रियाओं को कॉल करता है। संपूर्ण कॉलम नामों के साथ परिणाम सेट करना अच्छा है, खासकर जब कई टेबल शामिल हो जाते हैं और कई कॉलम वापस आ जाते हैं। आवेदन की इस प्रवृत्ति के साथ, मुझे विकल्प 2 पसंद है। मैं वास्तव में कॉलम के नाम को जॉइन पर देखना पसंद करता हूं। मैंने पुराने सिस्टम पर काम किया है जहाँ वे मेल नहीं खाते और यह एक बुरा सपना था,

Comments

गैर मिलान कॉलम नामों के साथ जुड़ने के लिए +1

— राज मोरे

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

— रसेल स्टीन

आज की कला अनुप्रयोगों की स्थिति कुछ ही वर्षों में पुरानी हो जाएगी । आप इंटरफ़ेस को फिर से लिख सकते हैं, या किसी अन्य प्लेटफ़ॉर्म में डेटा का उपयोग कर सकते हैं, लेकिन आपके डेटा (आपके कॉलम नामों सहित) को समय की कसौटी पर खड़ा होना होगा।

— के.एम.

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

— रसेल स्टैन

अच्छी तरह से तर्कपूर्ण बौद्धिक प्रतिक्रिया के लिए धन्यवाद।

— रसेल स्टैन

Answer 4

न तो सम्मेलन सभी मामलों में काम करता है, इसलिए किसी के पास क्यों है? सामान्य ज्ञान का उपयोग करें...

उदाहरण के लिए, सेल्फ-रेफरेंसिंग टेबल के लिए, जब एक से अधिक FK कॉलम होते हैं, जो एक ही टेबल के PK को सेल्फ-रेफर करता है, तो आपको दोनों "मानकों" का उल्लंघन करना होगा, क्योंकि दो FK कॉलम को एक ही नाम नहीं दिया जा सकता है ... उदा। , EmployeeId PK, SupervisorId FK, MentorId Fk, PartnersId FK, के साथ EmployeeTable ...

Comments

वास्तविक तकनीकी वस्तुनिष्ठ उत्तर के लिए +1

— DVK

एक अच्छा, लागू उत्तर, लेकिन डेम्स के उत्तर के तर्क बिंदु को याद करते हैं।

— जेल्टन

Answer 5

मैं सहमत हूं कि उनके बीच चयन करने के लिए बहुत कम है। मेरे लिए या तो मानक के बारे में बहुत अधिक महत्वपूर्ण बात "मानक" भाग है।

अगर लोग 'अपने काम खुद करना' शुरू करते हैं, तो उन्हें अपने सेठों से लड़ना चाहिए। IMHO :)

Comments

+1 यह मानने के लिए कि संगति "सही" होने से अधिक महत्वपूर्ण है (इस मामले में)

— रसेल स्टीन

-1 "मूर्खता संगति" लागू करने के प्रयास के लिए। पुरानी चीनी कहावत कहती है, "एक मूर्खता, साधारण दिमाग के लिए एक मूर्खता है।"

— चार्ल्स ब्रेटाना

@charles: ऐसी दुनिया में जहां अलग-अलग लोग एक-दूसरे के कोड को बनाए रखते हैं, अक्सर जब लेखक ने छोड़ दिया है और प्रलेखन अप्रचलित या गैर-मौजूद है, तो यह एक मूर्खता नहीं है। मुझे खुशी है कि मैं आपके साथ काम नहीं कर रहा हूँ ...

— MatBailie

@ लगता है, कोई अपराध का इरादा नहीं है, लेकिन यह मूर्खतापूर्ण है, दो कारणों से। 1) आम, स्पष्ट रूप से समझे जाने वाले परिदृश्य हैं जहां किसी भी मानक का उल्लंघन किया जाएगा। (उदाहरणों और 2 के लिए मेरा उत्तर देखें) क्योंकि इस मुद्दे पर, कम से कम, एक मानक बहुत कम मूल्य जोड़ देगा, सिवाय उन लोगों को बनाने के लिए जो मानकों को अधिक सहज महसूस करते हैं ...

— चार्ल्स ब्रेटाना

आप तर्क कर सकते हैं "आईडी" अधिक सुसंगत है - क्योंकि जैसे ही आप "कार" तालिका या "कार" तालिका में अंग्रेजी भाषा "कारिड" पेश करते हैं? "भेड़" "भेड़" मेज या "भेड़" में - चीजें असंगत होने लगती हैं। यदि आप "ID" और एकवचन तालिका नामों से चिपके रहते हैं - यह न केवल संगत है, बल्कि कई ORM के साथ अच्छा खेलता है / इसके लिए कम विन्यास की भी आवश्यकता होती है (जैसे Dapper Contrib)

— niico

Answer 6

क्या आपने निम्नलिखित पर विचार किया है?

Primary Table (Employee)   
Primary Key is PK_Employee

Foreign table (Event)  
Foreign key is called FK_Employee

Comments

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

— जेरेमी

इस पर ध्यान दिलाने के लिए धन्यवाद। मुझे उन कारणों में भी दिलचस्पी होगी कि आप इस प्रारूप का उपयोग क्यों नहीं करेंगे । और मैं कर रहा हूँ काफी यकीन है कि वहाँ अच्छे कारणों ... हो जाएगा

— Wouter

यह सबसे अच्छा तरीका है, क्योंकि आपको table_name.column_nameप्रश्नों में उपयोग नहीं करना होगा और कॉलम नामों के लिए उपनाम का उपयोग नहीं करना होगा यदि आपके पास बार-बार नाम नहीं हैं ...

— कृपया

इसे हंगेरियन नोटेशन का एक रूप माना जा सकता है। अतः उसके पक्ष में और उसके विरुद्ध तर्कों पर विचार करें।

— फ्रेड

Answer 7

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

Comments

अगर मुझे बहुवचन तालिका नाम पसंद हैं तो मैंने फैसला नहीं किया है। एकवचन का उपयोग करके प्रश्न बेहतर ("कर्मचारी.नाम" के विपरीत "कर्मचारी.नाम") पढ़ने लगते हैं। यहां तक ​​कि जुड़ने में भी यह बेहतर लगता है क्योंकि आप एकल रिकॉर्ड को किसी अन्य तालिका में शामिल कर रहे हैं। लेकिन बहुवचन तालिका के नाम क्वेरी के बजाय तालिका के बारे में सोचते समय अधिक सटीक लगते हैं। मैं एकवचन के साथ चिपके रहूंगा जैसा कि हम उपयोग करते हैं, लेकिन मुझे लगता है कि यह भी जाने का सही तरीका है (हालांकि फिर से, कई असहमत)

— MatBailie

हाँ। यह एक व्यक्तिगत प्राथमिकता और / या जो कुछ भी आप देखने के लिए उपयोग कर रहे हैं, मुझे लगता है कि अधिक है।

— जेरेत मिलार्ड

Answer 8

यदि आप एप्लिकेशन कोड देख रहे हैं, न कि केवल डेटाबेस क्वेरी, तो कुछ चीजें मुझे स्पष्ट लगती हैं:

1. तालिका परिभाषाएं आमतौर पर एक वर्ग के लिए सीधे मैप करती हैं जो एक वस्तु का वर्णन करता है, इसलिए उन्हें एकवचन होना चाहिए। किसी वस्तु के संग्रह का वर्णन करने के लिए, मैं आमतौर पर "Array" या "List" या "Collection" को एकवचन के नाम से जोड़ देता हूं, क्योंकि यह बहुवचन के उपयोग से अधिक स्पष्ट रूप से इंगित करता है कि न केवल यह एक संग्रह है, बल्कि किस प्रकार का संग्रह है यह है। उस दृश्य में, मुझे एक तालिका नाम दिखाई देता है, जो संग्रह का नाम नहीं है, बल्कि उस वस्तु के प्रकार का नाम है, जिसका वह संग्रह है। एक डीबीए जो आवेदन कोड नहीं लिखता है वह इस बिंदु को याद कर सकता है।

2. गैर-महत्वपूर्ण पहचान उद्देश्यों के लिए मैं अक्सर जिस डेटा से निपटता हूं वह "आईडी" का उपयोग करता है। मुख्य कुंजी नाम के लिए "ID" और गैर-कुंजी "ID" s के बीच भ्रम को समाप्त करने के लिए, हम "Key" (यह वही है, यह नहीं है?) तालिका नाम या संक्षिप्त नाम के साथ उपसर्ग का उपयोग करते हैं। तालिका का नाम। यह प्रीफ़िक्सिंग (और मैं इसे केवल प्राथमिक कुंजी के लिए आरक्षित करता हूं) कुंजी नाम को विशिष्ट बनाता है, जो विशेष रूप से महत्वपूर्ण है क्योंकि हम चर नामों का उपयोग करते हैं जो डेटाबेस स्तंभ नामों के समान हैं, और अधिकांश कक्षाओं में एक अभिभावक होता है, जिसे नाम से पहचाना जाता है मूल कुंजी। यह सुनिश्चित करने के लिए भी आवश्यक है कि यह एक आरक्षित कीवर्ड नहीं है, जो "की" अकेला है। मुख्य चर नामों को बनाए रखने की सुविधा के लिए, और उन कार्यक्रमों के लिए प्रदान करना जो प्राकृतिक जुड़ाव करते हैं, विदेशी कुंजी का वही नाम होता है जिसका उपयोग उस तालिका में किया जाता है जिसमें वे प्राथमिक कुंजी होते हैं। मेरे पास एक से अधिक बार सामना करने वाले कार्यक्रम हैं जो प्राकृतिक जुड़नों का उपयोग करके इस तरह से बेहतर काम करते हैं। इस अंतिम बिंदु पर, मैं स्वयं-संदर्भित तालिकाओं के साथ एक समस्या स्वीकार करता हूं, जिसका मैंने उपयोग किया है। इस मामले में, मैं विदेशी कुंजी नामकरण नियम का अपवाद बनाऊंगा। उदाहरण के लिए, मैं उस तालिका में किसी अन्य रिकॉर्ड की ओर इशारा करने के लिए कर्मचारी तालिका में एक विदेशी कुंजी के रूप में ManagerKey का उपयोग करूंगा।

Comments

कई ऑब्जेक्ट-रिलेशनल मैपर्स (ओआरएम) जैसे कि एंटिटी फ्रेमवर्क आपको एक टेबल को एक अलग नाम के साथ कक्षा में मैप करने की अनुमति देता है। यह आपको "उपयोगकर्ता" नामक एक वर्ग और "उपयोगकर्ता" नाम की एक तालिका रखने की अनुमति देता है।

— फ्रेड

Answer 9

मुझे इस विषय पर शोध करने में # 2 सम्मेलन पसंद है, और अपना प्रश्न पोस्ट करने से पहले यह पता लगाना, मैं इस मुद्दे पर भाग गया जहाँ:

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

SELECT table1.id AS parent_id, table2.id AS child_id

हालांकि कन्वेंशन # 2 का उपयोग करने का मतलब है कि मेरे पास अभी भी उसी नाम के साथ परिणाम में कुछ कॉलम होंगे, मैं अब निर्दिष्ट कर सकता हूं कि मुझे कौन सी आईडी की आवश्यकता है (माता-पिता या बच्चे) और, जैसा कि स्टीवन ह्यूविग ने सुझाव दिया था, USINGकथन आगे की चीजों को सरल करता है।

Comments

SELECT *(अधिकांश) उत्पादन प्रश्नों के लिए कोई-कोई नहीं है, वैसे भी, इसलिए यह एक नामकरण मानक चुनने के लिए बहुत कारण नहीं है।

— पी डैडी

असहमति नहीं: क्या आप ऐसा करने के लिए एक लिंक प्रदान कर सकते हैं कि ऐसा क्यों है? मुझे अपनी क्वेरी में 80 कॉलम के नाम बनाए रखने का विचार पसंद नहीं है।

— येल्टन

इस समय एक लिंक नहीं मिल सकता है ("*" के लिए Google के लिए कठिन), लेकिन मैं मूल बिंदुओं को रेखांकित करूंगा: (1) तालिका में परिवर्तन आपके आवेदन को नकारात्मक रूप से प्रभावित कर सकते हैं, (2) यह हो सकता है प्रदर्शन के लिए बुरा है, और (3) स्पष्ट रूप से निर्दिष्ट करना कि आपको वास्तव में क्या डेटा चाहिए, जिससे आपके कोड को समझने में आसानी हो। इन बिंदुओं का विस्तार हो सकता है, और अपवाद हैं (जैसा कि मैंने कहा था) लेकिन यह यहां उचित नहीं है। यदि आप इसे एक नए प्रश्न के रूप में पोस्ट करते हैं, तो मुझे (और अन्य) आगे विस्तार से खुशी होगी।

— पी डैडी

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

— येल्टन

मुझे यकीन नहीं है कि SELECT *अधिकांश उत्पादन प्रश्नों के लिए कोई नहीं है। यदि यह आपके विकास की गति को काफी बढ़ा देता है, और आपके कोड को अधिक महत्वपूर्ण और पठनीय बनाता है - तो आपको अधिक महत्वपूर्ण मामलों पर ध्यान केंद्रित करने की अनुमति मिलती है - क्यों नहीं SELECT *? यह प्रत्येक स्थिति की परिस्थितियों पर बहुत निर्भर करता है और कई कारकों के बीच एक व्यापार है। एक नियम शायद ही कभी सब कुछ फिट बैठता है।

— नीको

Answer 10

मैं हमेशा एक मेज पर एक PK के रूप में userId और एक FK के रूप में एक और मेज पर userId का उपयोग किया है। उपयोगकर्ता से एक के रूप में पहचान करने के लिए नाम के रूप में userIdPK और userIdFK का उपयोग करने के बारे में गंभीरता से सोच रहा हूँ । तालिकाओं को देखते हुए पीके और एफके को जल्दी पहचानने में मुझे मदद मिलेगी और ऐसा लगता है कि डेटा को एक्सेस करने के लिए PHP / SQL का उपयोग करते समय यह कोड को साफ कर देगा। खासतौर पर तब जब कोई और मेरा कोड देखता है।

Answer 11

मैं सम्मेलन # 2 का उपयोग करता हूं। मैं अब एक विरासत डेटा मॉडल के साथ काम कर रहा हूं जहां मुझे नहीं पता कि किसी तालिका में क्या है। क्रिया होने में नुकसान कहाँ है?

Answer 12

विदेशी कुंजी के नामकरण के बारे में कैसे

ROLE_ID

भूमिका भूमिका संदर्भित इकाई हाथ में टेबल के लिए सापेक्ष है। यह एक ही तालिका में पुनरावर्ती संदर्भ और कई fks के मुद्दे को हल करता है।

कई मामलों में संदर्भित तालिका नाम के समान होगा। इस मामले में यह आपके प्रस्तावों में से एक के लिए पहचान बन जाता है।

किसी भी मामले में हविन लंबी बहस एक बुरा विचार है

Answer 13

"जहां" कर्मचारी INNER JOIN आदेश पर आदेश ।employee_id = कर्मचारी।

अतिरिक्त योग्यता की कोई आवश्यकता नहीं है क्योंकि मैंने जिस योग्यता की बात की है, वह पहले से ही है।

"कारण यह है कि एक व्यावसायिक उपयोगकर्ता ऑर्डर आईडी या कर्मचारी आईडी को संदर्भित करता है, लेकिन संदर्भ प्रदान करने के लिए है, लेकिन एक डीबीएएस स्तर पर आपके पास पहले से ही संदर्भ है क्योंकि आप तालिका के लिए रेफरी कर रहे हैं"।

प्रार्थना करें, मुझे बताएं, यदि स्तंभ का नाम 'आईडी' है, तो वह "रेफ़रिंग [sic] टेबल" कैसे की जाती है, जब तक कि यह संदर्भ आईडी आईडी कॉलम के योग्य नहीं है, जब तक मैंने बात की थी?