तालिका के प्राथमिक कुंजी स्तंभ "आईडी" को नाम देना क्यों बुरा व्यवहार माना जाता है? [बन्द है]

Question

मेरे t-sql शिक्षक ने हमें बताया कि हमारे PK कॉलम का नामकरण "Id" बिना किसी और स्पष्टीकरण के बुरा व्यवहार माना जाता है।

पीके कॉलम "आईडी" का नामकरण क्यों बुरा माना जाता है?

Comments

खैर, यह वास्तव में विवरण नहीं है और आईडी का अर्थ "पहचान" है जो बहुत ही आत्म व्याख्यात्मक है। यही मेरी राय है।

— जीन-फिलिप लेक्लेर

मुझे यकीन है कि वहाँ बहुत सी दुकानें हैं जो Id का उपयोग PK नाम के रूप में करती हैं। मैं व्यक्तिगत रूप से अपने नामकरण सम्मेलन के रूप में TableId का उपयोग करता हूं, लेकिन मैं किसी को भी इसका सही तरीका नहीं बताऊंगा। ऐसा लगता है कि आपका शिक्षक सिर्फ अपनी राय को व्यापक रूप से स्वीकृत सर्वोत्तम अभ्यास के रूप में प्रस्तुत करने की कोशिश कर रहा है।

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

— deadalnix

आपके पास एक तालिका है ... इसे लोग कहते हैं, इसे एक कॉलम मिला है, जिसे आईडी कहा जाता है, आपको क्या लगता है कि आईडी क्या है? एक गाडी? एक नाव? ... नहीं, यह लोग ईद है, यह बात है। मुझे नहीं लगता कि यह एक बुरा अभ्यास नहीं है और ईद के अलावा पीके कॉलम को नाम देना जरूरी नहीं है।

— -'११

तो शिक्षक कक्षा के सामने जाता है और आपको बताता है कि यह एक भी कारण के बिना एक बुरा अभ्यास है? एक शिक्षक के लिए यह एक बुरा अभ्यास है।

— जेफ़ओ

Answer 1

मैं बाहर आकर यह कहने जा रहा हूँ: यह वास्तव में एक बुरा अभ्यास नहीं है (और यदि ऐसा है, तो यह उतना बुरा नहीं है )।

आप तर्क दे सकते हैं (जैसा कि चाड ने बताया है) कि यह निम्नलिखित क्वेरी में त्रुटियों की तरह कर सकता है:

SELECT * 
    FROM cars car
    JOIN manufacturer mfg
        ON mfg.Id = car.ManufacturerId
    JOIN models mod
        ON mod.Id = car.ModelId
    JOIN colors col
        ON mfg.Id = car.ColorId

लेकिन यह आसानी से अपने टेबल के नाम के लिए छोटे उपनामों का उपयोग न करके कम किया जा सकता है:

SELECT * 
    FROM cars
    JOIN manufacturer
        ON manufacturer.Id = cars.ManufacturerId
    JOIN models
        ON models.Id = cars.ModelId
    JOIN colors
        ON manufacturer.Id = cars.ColorId

कॉलम नाम का उपयोग करने की तुलना में ALWAYS का 3 अक्षर संक्षिप्तिकरण का अभ्यास मुझे बहुत बुरा लगता है id। (बिंदु में मामला: जो वास्तव में संक्षिप्त नाम के carsसाथ तालिका का नाम संक्षिप्त carकरेगा? वह क्या सेवा करता है?)

मुद्दा यह है: सुसंगत होना। यदि आपकी कंपनी आईडी का उपयोग करती है और आप सामान्यतः ऊपर त्रुटि करते हैं, तो पूर्ण तालिका नामों का उपयोग करने की आदत डालें। यदि आपकी कंपनी आईडी कॉलम पर प्रतिबंध लगाती है, तो इसे स्ट्राइड में लें और जो भी नामकरण सम्मेलन पसंद करते हैं उसका उपयोग करें।

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

---

संपादकों के लिए एक नोट: इस क्वेरी में त्रुटि जानबूझकर है और इसका उपयोग एक बिंदु बनाने के लिए किया जा रहा है। कृपया संपादन से पहले पूरा उत्तर पढ़ें।

Comments

@ क्या, यह इस तथ्य का संदर्भ था कि उस विशेष क्वेरी में आपने उपनामों के लिए 3 अक्षरों का उपयोग टेबल नामों के लिए किया था, तब भी जब इसका कोई मतलब नहीं था ( cars-> carभगवान का शुक्र है - आपने मेरी उंगलियां बचा लीं)। इसे बहुत गहराई से न पढ़ें।

— रिवलॉक

मेरे उपनामों से भी बदतर, मेरी बहुलता का मिश्रण था carsऔर manufacturer। एक बहुवचन है, दूसरा नहीं है। यदि लोग db पर चुनना चाहते हैं, तो यह बुरा अभ्यास है जिसे चुना जाना चाहिए।

— कैफीक ने

मुझे लगता है कि यह बुरा अभ्यास है। जाहिर है, जहां तक ​​बुरा अभ्यास चला जाता है यह भयानक नहीं है .. लेकिन इससे बचना इतना आसान है, ऐसा क्यों नहीं करते? अब, मैं सहमत हूं, एक परिचय वर्ग के लिए, क्या यह ध्यान केंद्रित करने की चीज है? शायद नहीं ....

— user606723

@ user606723, वास्तव में, मुझे लगता है कि एक इंट्रो क्लास के लिए यह एक महत्वपूर्ण बात है। सर्वोत्तम प्रथाओं को सिखाना मौलिक होना चाहिए। यह तब तक नहीं है जब तक आपको अनुभव न हो कि आप परिणाम और व्यापार को समझते हैं और जब आपको सर्वोत्तम प्रथाओं से विचलन करना चाहिए।

— कैफीक गत

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

— user606723

Answer 2

क्योंकि जब आपके पास एक विदेशी कुंजी के साथ एक तालिका होती है, तो आप उस विदेशी कुंजी "आईडी" का नाम नहीं दे सकते। आपके पास तालिका का नाम है यह TableId

और फिर आपका जुड़ाव दिखता है

SELECT * FROM cars c JOIN manufacturer m ON m.Id = c.ManufacturerId

और आदर्श रूप से, आपकी स्थिति में प्रत्येक तरफ समान फ़ील्ड नाम होना चाहिए

SELECT * FROM cars c JOIN manufacturer m ON m.ManufacturerId = c.ManufacturerId

जब तक कि मुझे Id को निर्माता नाम के रूप में निरर्थक लगता है, यह कम संभावना बनाता है कि आपके पास अपनी शर्तों में त्रुटियां हैं क्योंकि गलतियां स्पष्ट हैं।

यह आसान लगता है, लेकिन जब आप कई तालिकाओं में शामिल होते हैं, तो यह अधिक संभावना है कि आप एक गलती करेंगे, नीचे एक को ढूंढें ...

SELECT * 
    FROM cars car 
    JOIN manufacturer mfg
        ON mfg.Id = car.ManufacturerId
    JOIN models mod
        ON mod.Id = car.ModelId
    JOIN colors col
        ON mfg.Id = car.ColorId

जबकि उचित नामकरण के साथ, त्रुटि बाहर चिपक जाती है ...

SELECT * 
    FROM cars car 
    JOIN manufacturer mfg
        ON mfg.ManufacturerId = car.ManufacturerId
    JOIN models mod
        ON mod.ModelId = car.ModelId
    JOIN colors col
        ON mfg.ManufacturerId = car.ColorId

उन्हें आईडी नाम देने का एक और कारण यह है कि जब आप कई तालिकाओं की जानकारी के लिए क्वेरी कर रहे होते हैं, तो यह है कि आपको आईडी कॉलम का नाम बदलना होगा ताकि आप उन्हें अलग कर सकें।

SELECT   manufacturer.Id as 'ManufacturerId'
        ,cars.Id as 'CarId'
        --etc
    FROM cars 
    JOIN manufacturer
        ON manufacturer.Id = cars.Id

सटीक नामों के साथ यह एक मुद्दे से कम है

Comments

सुनिश्चित नहीं है कि यह मेरे लिए एक अच्छा पर्याप्त स्पष्टीकरण है। कहने में कुछ गलत नहीं है SELECT * FROM cars c JOIN manufacturer m ON manufacturer.Id = c.ManufacturerId। मैंने idवर्षों तक उपयोग किया है और कभी नहीं पाया कि आपने वास्तविक समस्या क्या बताई।

— रिवलॉक

मैं कहूंगा कि यहाँ बुरा अभ्यास mfg या mod जैसे नाम वाली अन्य तालिकाओं के लिए है। निर्माताओं .id = Cars.manufacturer_id बहुत पठनीय है और त्रुटि भी दूर होगी।

— deadalnix

@ चाद> मुझे पहले से ही डम्ब चर नामों के साथ समस्या थी। कई बार। रेकॉर्ड के लिए, यहां मैं एक देव से क्या कहूंगा जो मेरी टीम में ऐसा करता है «mfg का मतलब निर्माता नहीं है, इसका मतलब है कि आप निर्माता को टाइप करने के लिए आलसी हैं।

— deadalnix

@ Stargazer712: 2 टेबल से सेलेक्ट * करने से 2 x आईडी कॉलम मिलता है। आईडी अब अस्पष्ट है: क्या आप अध्यादेश या नाम से संदर्भ देते हैं? चयन * भी अच्छा अभ्यास नहीं है। खराब तर्क। नाजुक कोड। चाड सही है: रक्षात्मक कोडिंग मूल रूप से

— gbb

@ फिर, अगर आप बस करते हैं, तो सारी अस्पष्टता दूर हो जाती है SELECT manufacturer.id FROM ...। इससे होने वाली हर कठिनाई idको बहुत आसानी से दूर किया जा सकता है, जिससे यह केवल स्वाद की चीज है।

— रिवलॉक १alk

Answer 3

रूबी की ActiveRecord लाइब्रेरी और Groovy's GORM डिफ़ॉल्ट रूप से सरोगेट कुंजी के लिए "id" का उपयोग करते हैं। मुझे यह अभ्यास पसंद है। प्रत्येक स्तंभ नाम में तालिका नाम की नकल निरर्थक है, लिखने के लिए थकाऊ, और पढ़ने के लिए अधिक थकाऊ।

Comments

+1 के लिए "और पढ़ने के लिए अधिक थकाऊ।" - नामकरण परंपराओं को मैला कोड के लिए एक बैंड-सहायता के रूप में नहीं सोचा जाना चाहिए, उन्हें प्राथमिक चिंता के रूप में पठनीयता में सुधार करना चाहिए।

— ओकोडो

आईडी पढ़ने के लिए कहीं अधिक थकाऊ है

— HLGEM

@ एचएलजीईएम: कोई भी हमेशा टेबल नाम के साथ कॉलम नाम को क्वालिफाई कर सकता है।

— केविन क्लाइन

मैं पढ़ने के लिए अधिक थकाऊ को छोड़कर सहमत होगा। मैं वास्तव में अधिक वर्णनात्मक कॉलम नाम पढ़ना पसंद करता हूं और यह जानने के लिए कम समय बिताता हूं कि वास्तव में वह कॉलम क्या है।

— डेविन डिक्सन

+1, Post.postID, Posts.postName जैसे स्तंभों के साथ तालिकाओं को देखने से घृणा करें, जहां केवल post.id और post.name का उपयोग करना अभी तक बहुत पुराना है।

— डग

Answer 4

"नाम" या "आईडी" जैसे सामान्य या प्रमुख स्तंभ नामों को तालिका नाम के साथ उपसर्ग किया जाना चाहिए।

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

कम इस्तेमाल किया या ऑडिट कॉलम या गैर-कुंजी (कहते हैं LastUpdatedDateTime) कोई फर्क नहीं पड़ता

Comments

यदि आप ऐसा करते हैं, तो मुझे अतिरिक्त टाइपिंग करने के लिए आपसे नफरत है !!!! तालिका का नाम व्यक्ति है, आपको क्या लगता है कि आईडी बनने जा रही है? गाड़ी? नहीं, यह व्यक्ति है।

— जिम

@ जिम, मैं आपके बारे में नहीं जानता, लेकिन 6 अतिरिक्त अक्षर टाइप करने से मुझे लगभग आधा सेकंड लगता है। और यह देखते हुए कि मैं शायद ही कभी एक तालिका से चयन करता हूं, और इस प्रकार 'Id' नाम के दो कॉलम समाप्त हो जाएंगे और किसी भी तरह तालिका / उपनाम नाम को शामिल करने की आवश्यकता होगी, टाइप किए गए वर्णों की संख्या में कोई बचत नहीं है।

— कैफ़ीक गीक

@ क्या मुझे यह बहुत अच्छा लग रहा है। अगर मैं एक जॉइन कर रहा हूं, तो c.id = m.manufacturerid, मेरे साथ ठीक है। ये कॉलम आम तौर पर किसी वर्ग के लिए "मैप" किया जाता है, और Person.PersonId के साथ एक वर्ग रखने के लिए मुझे उल्टी करना चाहता है ... हां, मुझे पूरी तरह से पता है कि मेरे पास मुद्दे हैं।

— जिम

मैं इससे भी असहमत हूं। पर nameऔर क्यों रुके id? क्यों हर स्तंभ अपने तालिका नाम के साथ उपसर्ग नहीं करता है? एक उपसर्ग को अनिवार्य करने के लिए उन दो नामों को चुनना मनमाना लगता है। वैचारिक रूप से, आपके पास वैसे भी स्तंभ का संदर्भ रखने के लिए तालिका होनी चाहिए। केवल क्वेरी को स्पष्ट करने के लिए उस तालिका नाम का उपयोग क्यों न करें: Person.Name, Animal.Name, Part.Name, ...

— थॉमस

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

— HLGEM

Answer 5

यह धागा मर चुका है, लेकिन मैं यह जोड़ना चाहूंगा कि IMO का उपयोग नहीं करना Idएक बुरा व्यवहार है। Idस्तंभ खास है; यह है प्राथमिक कुंजी। किसी भी तालिका में कोई भी विदेशी कुंजी हो सकती है, लेकिन इसमें केवल एक कुंजी हो सकती है जो प्राथमिक है। एक डेटाबेस में जहां सभी प्राथमिक कुंजियों को कहा जाता है , जैसे ही आप तालिका को देखते हैं, आपको पता होता है कि प्राथमिक कुंजी कौन सा कॉलम है।Id

मेरा विश्वास करो, अब महीनों के लिए मैंने हर दिन बड़े डेटाबेस (सेल्सफोर्स) के बहुत सारे काम करते हुए बिताया है और स्कीमा के बारे में मैं सबसे अच्छी बात यह कह सकता हूं कि प्रत्येक तालिका में एक प्राथमिक कुंजी है Id। मैं आपको आश्वस्त कर सकता हूं कि मैं एक विदेशी कुंजी के लिए प्राथमिक कुंजी में शामिल होने के बारे में बिल्कुल भ्रमित नहीं हूं क्योंकि पीके कहा जाता है Id। एक और बात जिसका लोगों ने उल्लेख नहीं किया है वह यह है कि तालिकाओं में लंबे मूर्ख नाम हो सकते हैं Table_ThatDoesGood_stuff__c; यह नाम काफी बुरा है क्योंकि आर्किटेक्ट को सुबह उस टेबल पर लगा एक हैंगओवर था, लेकिन अब आप मुझे बता रहे हैं कि प्राथमिक कुंजी को कॉल न करने के लिए यह बुरा अभ्यास है Table_ThatDoesGood_stuff__cId (यह याद रखना कि SQL स्तंभ नाम सामान्य स्थिति में संवेदनशील नहीं हैं)।

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

Comments

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

— निकोडेमस

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

— पीटर बी

यह जवाब सिर्फ ऐसा लगता है जैसे आप कह रहे हैं "मैं पसंद करता हूं" आईडी "" राय के साथ तर्क दिया। आपका तर्क यह है कि आप तुरंत देख सकते हैं कि किस कुंजी को ईद कहा जाता है। खैर, यह टेबलआईड के साथ ठीक वैसा ही है । मैं आपको गारंटी दे सकता हूं कि मैं कभी भी भ्रमित नहीं हो सकता कि कौन सी कुंजी प्राथमिक कुंजी है। मैं सिर्फ उसी को खोजता हूं जिसमें आईडी से पहले टेबल का नाम है। इतना ही नहीं, लेकिन आप किस तरह की भारी तालिकाओं के साथ काम कर रहे हैं जहां पहला कॉलम प्राथमिक कुंजी नहीं है? मुझे लगता है कि इस उत्तर में आपके सभी तर्क शुद्ध रूप से तरजीही आधारित हैं और "tableId मुझे गलत लगता है"।

— डेलिन

@ सभी जवाबों के बारे में बताया गया है, अन्यथा कोई व्यक्ति आधिकारिक मानक से जुड़ेगा, और कोई नहीं है!

— जेम्स

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

— dallin

Answer 6

मैं इसे बुरा व्यवहार नहीं मानता। संगति राजा है, हमेशा की तरह।

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

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

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

Comments

रिलेशनल डेटाबेस टेबल क्लासेस नहीं हैं ।

— एडम रॉबिन्सन

हालांकि वे डेटा संरचनाएं हैं और वे PODO कक्षाओं के अनुरूप हैं। वही नामकरण की समस्याएं लागू होती हैं।

— ओसोडो

@Slomojo: नहीं, वे साधारण वस्तुओं के अनुरूप नहीं हैं। ऑब्जेक्ट-ओरिएंटेड डिज़ाइन और डेटाबेस डिज़ाइन समान नहीं हैं, और संबंधित भी नहीं हैं। हालांकि, वे कुछ मामलों में, समान (या समान) डिजाइन प्राप्त कर सकते हैं, यह इंगित नहीं करता है कि वे संबंधित हैं। उदाहरण के लिए, m: m संबंध कक्षाओं में तुच्छ होते हैं, लेकिन बिना किसी तीसरे संघ के तालिका के दो तालिकाओं के बीच असंभव है।

— एडम रॉबिन्सन

काफी यह कैसे एक नामकरण रणनीति से संबंधित है, मुझे नहीं पता। मेरी सादृश्य है (स्पष्ट रूप से?) केवल उस सीमा तक।

— ओकोडो

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

— ओसोडो

Answer 7

से data.stackexchange.com

बूम, सवाल का जवाब दिया।
अब अपने शिक्षक को बताएं कि SO खराब डेटाबेस डिज़ाइन का अभ्यास करता है।

Comments

FKs पर मेरा अनुमान, नामों के आधार पर PostTypeId -> PostTypes.Id:; AcceptedAnswerId -> Answers.Id; OwnerUserId -> Users.Id। ऐसा अभ्यास क्यों किया जाना चाहिए जो उस आसान को 'बुरा' माना जाए?

— सोज़ेरड

यह वास्तव में सर्वोत्तम प्रथाओं के बारे में कुछ भी कैसे साबित करता है?

— 15

स्टैक पर किसी चीज का उपयोग किया जाता है या नहीं यह साबित नहीं होता है कि यह अच्छा है या बुरा।

— पीटर बी

यह क्या साबित करता है कि यह अभ्यास किसी भी तरह से अनुप्रयोग की मापनीयता और उपयोगिता को प्रतिबंधित नहीं करता है।

— साइफर

वास्तव में एसओ अभ्यास सही नहीं है। मैं इस नामकरण का उपयोग करूंगा: PostType -> PostType.Id; एक्सेप्टेडस्वैनर -> उत्तर.आई डी; मालिक -> User.Id

— 2:17 बजे

Answer 8

यह मेज पर एक प्राकृतिक जुड़ाव प्रदर्शन करने के लिए कठिन (और भ्रामक) बनाता है, इसलिए, हाँ, यह बहुत बुरा है अगर बुरा नहीं है।

नेचुरल जॉइन SQL लोर (यानी रिलेशनल अलजेब्रा) की एक प्राचीन कलाकृति है जो आपने इनमें से किसी एक: artifact डेटाबेस डेटाबेस में देखी होगी। मेरा मतलब है कि नैचुरल ज्वाइन एक नया फँसा हुआ एसक्यूएल विचार नहीं है, भले ही यह डीबीएमएस के लिए हमेशा के लिए लग रहा है इसे लागू किया गया है, इसलिए इसे लागू करने के लिए आपके लिए एक नया फँसा हुआ विचार नहीं है, यह आपको अनदेखा करने के लिए अनुचित भी हो सकता है। आजकल इसका अस्तित्व है।

ठीक है, यदि आप अपने सभी प्राथमिक कुंजी की आईडी का नाम देते हैं, तो आप प्राकृतिक जुड़ने की सहजता और सरलता खो देते हैं। select * from dudes natural join carsलिखा जा करने की आवश्यकता होगी select * from dudes inner join cars where cars.dudeid = dudes.idया select * from dudes inner join cars where dudes.carid = cars.id। यदि आप प्राकृतिक रूप से जुड़ने में सक्षम हैं, तो आप इस बात को नजरअंदाज कर सकते हैं कि वास्तव में क्या संबंध है, जो, मेरा मानना ​​है कि, बहुत बढ़िया है।

Comments

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

— बिल लीपर

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

— पीटर टर्नर

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

— थॉमस

@ थोमस, मैं कोड में प्राकृतिक जुड़ाव नहीं डालूंगा, लेकिन निदान के लिए, मैंने उन्हें बहुत उपयोगी पाया है जब डेटाबेस मॉडलिंग की जाती है ताकि वे वास्तव में काम करें।

— पीटर टर्नर

Answer 9

एक ऐसी स्थिति है जहां हर टेबल पर "आईडी" चिपके रहना सबसे अच्छा विचार नहीं है: USINGकीवर्ड, यदि यह समर्थित है। हम इसका उपयोग अक्सर MySQL में करते हैं।

उदाहरण के लिए, यदि आपके पास fooTableकॉलम है fooTableIdऔर barTableविदेशी कुंजी है fooTableId, तो आपके प्रश्नों का निर्माण इस प्रकार किया जा सकता है:

SELECT fooTableId, fooField1, barField2 FROM fooTable INNER JOIN barTable USING (fooTableId)

यह न केवल टाइपिंग को बचाता है, बल्कि विकल्प की तुलना में बहुत अधिक पठनीय है:

SELECT fooTable.Id, fooField1, barField2 FROM fooTable INNER JOIN barTable ON (fooTable.Id = barTable.foTableId)

Comments

यह वह जवाब है जो मेरे लिए सबसे अधिक चिपक गया है। यह USINGकीवर्ड पोस्टग्रेज / mysql / sqlite डेटाबेस द्वारा समर्थित है, जिसका अर्थ है कम टाइपिंग जो कुछ अन्य उत्तर सूची का उपयोग करने के कारण के रूप में करता है id, और अंत में मेरे व्यक्तिपरक राय में अधिक पठनीय है।

— माइकल बार्टन

Answer 10

सिर्फ अपने शिक्षक से ही क्यों न पूछें?

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

स्तंभ नामों को शब्दार्थ रूप से महत्वपूर्ण होना चाहिए। IDजेनेरिक है।

Comments

क्या के लिए भी सामान्य? एक मेज की आईडी?

— -'११

@ किस टेबल पर है? idअकेले कुछ भी मतलब नहीं है, विशेष रूप से एक अन्य तालिका के लिए एक विदेशी कुंजी के संदर्भ में। यह classesअच्छा बुनियादी मौलिक संबंध डेटाबेस डिजाइन के साथ करने के लिए और सब कुछ करने के लिए कुछ भी नहीं है ।

थोड़ा मोटा होने के लिए, यह जिस तालिका से संबंधित है। table.idएक idक्षेत्र का जिक्र करने के लिए एक पूरी तरह से स्वीकार्य तरीका है । फ़ील्ड नाम को तालिका नाम के साथ उपसर्ग करना निरर्थक है।

— ओसोडो

@Slomoj यह कॉलम में नाम शामिल करने की तुलना में अधिक टाइपिंग नहीं है और राक्षस जोड़ों में एकल या दोहरे अक्षर संक्षिप्त नाम तालिका नाम के साथ अधिक अन्वेषण करते हैं।

किस दुःस्वप्न की बात कर रहे हैं? मान लीजिए कि आपके पास अपने प्रबंधक का प्रतिनिधित्व करने वाले कॉलम के साथ कर्मचारियों की एक आत्म-संदर्भित संरचना है। आप विदेशी कुंजी को क्या कहते हैं? आप इसे EmployeeId नहीं कह सकते क्योंकि यह संभवतः आपका PK है। FK का नाम PK से मेल नहीं खाता है। यह उस नाम के लिए होना चाहिए जो उस इकाई का प्रतिनिधित्व करता है जिसमें यह निहित है।

— थॉमस

Answer 11

निम्नलिखित कारणों से आईडी खराब है:

यदि आप बहुत सारे रिपोर्टिंग क्वेश्चन करते हैं तो आपको हमेशा कॉलम देखना होगा अगर आप दोनों को देखना चाहते हैं। तो यह समय की बर्बादी बन जाता है जब आप इसे ठीक से नाम देना शुरू कर सकते हैं। ये जटिल प्रश्न काफी कठिन हैं (मैं ऐसे प्रश्न लिखता हूं जो अनावश्यक काम करने के अतिरिक्त बोझ के बिना सैकड़ों लाइनें लंबी हो सकती हैं)।

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

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

Comments

+1: ये मेरे विचार से सम्मोहक कारण हैं, जबकि अन्य उत्तर विरोध IDमुझे बिल्कुल नहीं समझाते।

— phoog

पुन: "यदि आप एक जटिल क्वेरी बनाने के लिए j नकल की नकल कर रहे हैं" - तो आपकी समस्या कॉपी और पेस्ट है। कॉपी और पेस्ट करना बंद करें और आप देखेंगे कि नामकरण कितना सुविधाजनक कार है। FK जॉइनिंग के लिए car.mfg = mfg.id, car.color = color.id, car.model = model.id - बहुत ही सरल है और जो आप LINQ में लिखेंगे उससे मेल खाता है।

— अल्फा

30 जॉइन के साथ कुछ लिखने की कोशिश करें और आप देखेंगे कि यह एक एंटीपैटर्न क्यों है।

— एचएलजीईएम

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

— लुलु

Answer 12

कुछ उत्तर हैं जो दृष्टिकोण को मैं "आईडी" का उपयोग नहीं करने के सबसे महत्वपूर्ण कारण पर विचार करेंगे क्योंकि तालिका में प्राथमिक कुंजी के लिए कॉलम नाम: अर्थात् स्थिरता और कम अस्पष्टता।

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

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

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

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

किसी के रूप में, जिसने सैकड़ों वर्षों से बड़ी परियोजनाओं को बनाए रखने में कई साल बिताए हैं, मैं दृढ़ता से तालिकाओं की कुंजी के लिए संगत नामों को प्राथमिकता दूंगा।

Comments

मान लीजिए कि एक Companiesटेबल में 2 विदेशी चाबियां हैं Persons। एक कंपनी के अध्यक्ष का प्रतिनिधित्व करता है; अन्य कंपनी के कोषाध्यक्ष का प्रतिनिधित्व करता है। क्या आप वास्तव में कॉलम PersonID1और कहेंगे PersonID2? यह उन्हें कॉल करने के लिए PresidentIDऔर अधिक विवरणात्मक होगा TreasurerID। मुझे पढ़ने में बहुत आसान लगता inner join Person AS Presidents ON Company.PresidentID = Presidents.IDहैinner join Person AS Person1 ON Company.PersonID1 = Person1.PersonID

— phoog

नहीं। आपके उदाहरण में, मेरे पास संभवतः एक CompanyOfficerया CompanyPersonतालिका होगी जो रिश्ते की प्रकृति के बारे में अतिरिक्त जानकारी के बीच Companyऔर Personसाथ कई-से-कई संबंधों की अनुमति देती है । यदि मुझे इसे Companyतालिका के भीतर लागू करना है , तो मैं अतिरिक्त विवरणक को जोड़ते हुए कॉलम के नामों का उपयोग करूँगा PresidentPersonIDऔर नाम TreasurerPersonIDके * PersonID भाग को संरक्षित करूंगा। inner join Person as Presidents on Company.PresidentPersonID = Presidents.PersonID

— मलाकी

Answer 13

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

और यही कारण है कि आईडी का उपयोग करना बुरा व्यवहार है: आईडी अक्सर केवल एक ऑटोइंकोर की जानकारी नहीं होती है।

निम्नलिखित तालिकाओं पर विचार करें:

PK id | Countryid   | Countryname
    1 |         840 | United States
    2 |         528 | the Netherlands

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

PK Countryid   | Countryname
           840 | United States
           528 | the Netherlands

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

Comments

आप समझेंगे कि जब आप अलग-अलग प्रणालियों के बीच डेटाबेस को स्थानांतरित करने के लिए, या डेटाबेस को एक साथ विलय करने का सुख प्राप्त कर चुके होते हैं, तो लोग प्रत्येक तालिका में एक सामान्य कुंजी कॉलम क्यों जोड़ते हैं।

— साइफर

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

— संहिताइंचोस

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

— गेरेट

@ गुजरात: अगर किसी देश का नाम बदलता है, तो आईएसओ 3166-1 संख्यात्मक कोड एक ही रहता है, केवल आईएसओ 3166-1 अल्फा -2 और अल्फा -3 कोड बदल जाते हैं। उदाहरण के लिए बर्मा / म्यांमार के साथ ऐसा हुआ। इसी तरह, अगर कोई देश अपना क्षेत्र बदलता है, लेकिन उसका नाम ISO 3166-1 संख्यात्मक कोड बदलता है, लेकिन ISO 3166-1 अल्फा -2 और अल्फा -3 कोड रहते हैं। यह तब हुआ जब दक्षिण सूडान सूडान से अलग हो गया और इरिट्रिया इथियोपिया से अलग हो गया। जब पूर्वी और पश्चिमी जर्मनी फिर से मिले, उन्होंने पश्चिम जर्मनी के अल्फा -2 और अल्फा -3 कोड रखे, लेकिन एक नया संख्यात्मक कोड मिला। जब देश पूरी तरह से भंग हो जाते हैं या बदल जाते हैं (सोचते हैं ...

— Jörg W Mittag

... 90 के दशक के बाल्कन युद्धों के परिणाम), वे दोनों नए संख्यात्मक और अल्फा -2 और अल्फा -3 कोड प्राप्त करते हैं।

— जोर्ग डब्ल्यू मित्तग

Answer 14

मैं हमेशा प्रत्येक तालिका के लिए प्राथमिक कॉलम नाम के रूप में 'आईडी' का उपयोग करता हूं क्योंकि यह उन फ्रेमवर्क का सम्मेलन है जो मैं उपयोग करता हूं (रूबी ऑन रेल्स, केकपीएचपीपी), इसलिए मुझे इसे हर समय ओवरराइड करने की आवश्यकता नहीं है।

यह मेरे लिए अकादमिक कारणों को नहीं हराएगा।

Answer 15

मुझे नहीं लगता कि अगर यह ठीक से उपयोग किया जाता है तो यह एक बुरा अभ्यास है। "आईडी" नामक एक ऑटो-इन्क्रिमेंटिंग आईडी फ़ील्ड होना आम है जिसे आपको कभी भी स्पर्श नहीं करना है, और एप्लिकेशन के लिए एक मित्र पहचानकर्ता का उपयोग करना है। कोड को लिखना थोड़ा बोझिल हो सकता है from tableA a inner join tableB b on a.id = b.a_idलेकिन उस कोड को टाल दिया जा सकता है।

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

Comments

आप प्रत्येक प्राथमिक कुंजी विशेषकर एक ऑटो-वृद्धि आईडी द्वारा दो तालिकाओं में शामिल नहीं होंगे। ऊपर का नमूना tableA से होगा। a.id = b.table_a_id पर एक आंतरिक जॉइन टेबलबी b।

— बिल लीपर

हाँ, यही मेरा मतलब है। लगभग दोपहर के भोजन और ऊर्जा की जरूरत है।

— वेन मोलिना

Answer 16

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

बस आशा है कि कोई भी एक sql डेटाबेस विकसित नहीं करता है जहाँ ID एक आरक्षित शब्द है।

CREATE TABLE CAR (ID);

क्षेत्र का नाम, प्राथमिक कुंजी, और ऑटो वेतन वृद्धि की देखभाल 1 से 1 अच्छे छोटे 2 वर्ण पैकेज में 1 से शुरू करता है। ओह, और मैंने इसे CARS कहा होगा, लेकिन अगर हम कुंजी स्ट्रोक पर बचत करने जा रहे हैं और कौन वास्तव में सोचता है कि CAR नामक तालिका केवल एक के पास है?

Comments

यह दर्शाता है कि औपचारिक संबंधपरक सिद्धांत का ज्ञान क्यों महत्वपूर्ण है, तालिका का नाम दर्शाता है कि एक पंक्ति क्या है। तालिका Carएक का प्रतिनिधित्व करती है, Tableजहां प्रत्येक Rowएकल का प्रतिनिधित्व करता है Car। Carsसिमेंटिक को बदलने में कॉल करना और औपचारिक संबंधपरक सिद्धांत मूल प्राचार्यों की समझ का पूर्ण अभाव दर्शाता है। रेल किसी का भी एक प्रमुख उदाहरण है जो खतरनाक होना जानता था ।

Answer 17

इस सवाल को बार-बार पीटा गया, लेकिन मुझे लगा कि मैं भी अपनी राय दूंगा।

1. मैं आईडी का उपयोग इस बात के लिए करता हूं कि प्रत्येक तालिका के लिए पहचानकर्ता है, इसलिए जब मैं किसी तालिका में शामिल होता हूं और मुझे प्राथमिक कुंजी की आवश्यकता होती है तो मैं स्वचालित रूप से प्राथमिक कुंजी में शामिल हो जाता हूं।

2. आईडी फ़ील्ड एक स्वत: अंकन है, अहस्ताक्षरित (जिसका अर्थ है कि मुझे इसका मूल्य कभी निर्धारित नहीं करना है और यह नकारात्मक नहीं हो सकता है)

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

4. आईडी छोटी है और प्यारी भी

5. अतिरिक्त सम्मेलन - सभी तालिका और स्तंभ नामों के लिए निचले मामले का उपयोग करें, इसलिए मामले के कारण कोई समस्या नहीं होनी चाहिए

Answer 18

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

उदाहरण के लिए, आप अपने स्कीमा को Visio जैसे टूल में लोड करने में असमर्थ होंगे और यह सटीक ERD का उत्पादन करेगा।

Comments

हालांकि यह तीसरे पक्ष के उपकरण की गलती होगी। कॉलम नामकरण परंपरा वास्तविक विदेशी कुंजी के लिए कोई विकल्प नहीं है, जिसे उपकरण को आत्मनिरीक्षण करना चाहिए।

— गेरट

Answer 19

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

यह अधिक या कम है कि लोग टेबल डेटा को कैसे पढ़ते हैं और वे अपना कोड कैसे लिखते हैं। मैं व्यक्तिगत रूप से और सबसे अधिक संभावना है कि यह सबसे लोकप्रिय तरीका है जिसे मैं अधिक बार देखता हूं कि कोडर्स पूरा संदर्भ लिखते हैं table.id, भले ही उन्हें यूनियन या / और जॉइन करने की आवश्यकता न हो। उदाहरण के लिए:

SELECT cars.color, cars.model FROM cars WHERE cars.id = <some_var>

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

इसलिए, यह जोड़ने के लिए कि मैं क्या जोड़ना चाहता था, यह केवल वरीयता का मामला है और एसक्यूएल पढ़ने का वर्णित तरीका सबसे लोकप्रिय है।

हालाँकि, कुछ ऐसे मामले हैं, जिनका उपयोग नहीं किया जाता है, जैसे कि (कहीं अधिक दुर्लभ उदाहरण) जब आईडी एक स्ट्रिंग है जो वास्तव में वर्णन कर रहा है। उदाहरण के लिए id = "RedFordMustang1970"या ऐसा ही कुछ। मुझे वास्तव में उम्मीद है कि मैं कम से कम विचार प्राप्त करने के लिए इसे समझा सकता हूं।