क्या आप डेटाबेस कॉलम की बात करते समय वर्बोज़ नामकरण पसंद करते हैं?

Question

आपकी वरीयता कौन सा है?

मान लें कि हमारे पास एक सामान्य उत्पाद तालिका है जिसमें एक आईडी, एक नाम और एक श्रेणी के लिए एक विदेशी कुंजी संदर्भ है। आप अपनी तालिका नाम के लिए की तरह पसंद करेंगे:

CREATE TABLE Products 
(
    ProductID int NOT NULL IDENTITY(1,1) PRIMARY KEY, 
    CategoryID int NOT NULL FOREIGN KEY REFERENCES Categories(CategoryID), 
    ProductName varchar(200) NOT NULL 
) 

स्तंभों के लिए स्पष्ट नामकरण का उपयोग कर (जैसे उत्पाद नाम, उत्पाद आईडी), या की तरह कुछ:

CREATE TABLE Products 
(
    ID int NOT NULL IDENTITY(1,1) PRIMARY KEY, 
    CategoryID int NOT NULL FOREIGN KEY REFERENCES Categories(ID), 
    Name varchar(200) NOT NULL 
) 

मैं क्या 'से हमने देखा है, .NET दुनिया में सम्मेलन स्पष्ट होना है - नमूने पहले उदाहरण का उपयोग करते हैं, जबकि ओपन सोर्स और आरओआर वर्ल्ड दूसरे पक्ष का पक्ष लेते हैं। व्यक्तिगत तौर पर मैं पहले पढ़ने में आसान और पहली नजर में समझने के लिए लगता है: select p.ProductID, p.ProductName, c.CategoryName from Categories c inner join Products p on c.CategoryID = p.CategoryID एक बहुत अधिक मेरे लिए प्राकृतिक select p.ID AS ProductID, p.Name AS ProductName, c.Name AS CategoryName from Categories c inner join Products p on c.ID = p.CategoryID

से मुझे लगता है कि लगता है कि मौलिक उदाहरण मैं प्रदान की यह एक बड़ी बात नहीं है, लेकिन कैसे के बारे में आप जब काम कर रहे हैं को देखते हुए बहुत सारे डेटा और टेबल के साथ? मुझे अभी भी दूसरे उदाहरण से बेहतर होने वाला पहला उदाहरण मिल जाएगा, हालांकि संभवतया दोनों के कुछ संयोजन आईडी के लिए (<Table>ID) में देखे जा सकते हैं, लेकिन नाम के लिए केवल Name?)। स्पष्ट रूप से एक मौजूदा परियोजना पर आपको पहले से स्थापित सम्मेलनों का पालन करना चाहिए, लेकिन नए विकास के बारे में क्या?

आपकी वरीयता क्या है?

Answer 1

तालिका का नाम पहले ही संदर्भ देता है। इसके साथ कॉलम नाम उपसर्ग करने की आवश्यकता नहीं है। टेबल में शामिल होने पर table.column वाक्यविन्यास का उपयोग करें।

Answer 2

मैं विकल्प 3 के एक प्रशंसक रहा हूँ:

CREATE TABLE Products 
(
    ProductId int NOT NULL IDENTITY(1,1) PRIMARY KEY, 
    CategoryId int NOT NULL FOREIGN KEY REFERENCES Categories(CategoryId), 
    Name varchar(200) NOT NULL 
) 

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

Answer 3

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

दूसरी तरफ, मैं कोडिंग के तर्क से पहले सोच के साथ कुछ डिग्री से सहमत हूं। मैं हमेशा table.column वाक्यविन्यास का उपयोग करता हूं, इसलिए संदर्भ स्पष्ट होना चाहिए।

अधिक वर्बोज़ कॉलम नामों का उपयोग आमतौर पर आरक्षित शब्दों के साथ संघर्ष से बचाता है।

फिर फिर, यदि आपके उत्पाद तालिका में प्रत्येक कॉलम ProductXxxx है तो यह काफी अनावश्यक हो सकता है।

दूसरे शब्दों में, मेरे पास पूर्ण प्राथमिकता नहीं है, लेकिन मैं वर्बोज नामकरण सम्मेलन की ओर अधिक प्रवृत्त हूं।

Answer 4

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

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

यह चीजों को सरल बनाता है।

Answer 5

मैं आमतौर पर प्रत्येक तालिका को एक अद्वितीय उपसर्ग देता हूं। तो अपने उदाहरण की तरह

CREATE TABLE Products 
(
    PROD_ID int NOT NULL IDENTITY(1,1) PRIMARY KEY, 
    PROD_CAT_ID int NOT NULL FOREIGN KEY REFERENCES Categories(CAT_ID), 
    PROD_NAME varchar(200) NOT NULL 
) 

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

हालांकि हाल ही में मैं यह बात शुरू कर रहा हूं कि (2) बेहतर हो सकता है, क्योंकि यह कोड लिखने के दौरान उपयोग किए जाने वाले नामकरण सम्मेलनों के करीब है (मेरे मामले में सी #)।

Answer 6

मैं जितना संभव हो उतना छोटा नाम रखता हूं। प्रत्येक कॉलम पर टेबल के नाम का उपसर्ग करने वाले लोग मुझे हिंसक बनाते हैं। PERSON.first_name, PERSON.person_first_name नहीं। हम इसे एक व्यक्ति जानते हैं, इसकी व्यक्तिगत तालिका में ... यह और क्या होगा?

एकमात्र बार जब मैं इस नियम के खिलाफ जाता हूं तो आईडी कॉलम के लिए होता है, उदाहरण के लिए: PERSON.personID।

नियम आइंस्टीन से माफी मांगने के साथ है; आवश्यक के रूप में verbose के रूप में होने के लिए, लेकिन कोई और verbose।

Answer 7

मैं uid, gid, पीआईडी, wid, ढक्कन, आदि पसंद करते हैं .. आप जुड़ जाता है की बहुत सारी है जब

Answer 8

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

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

Answer 9

चेक भी संबंधित प्रश्न: Is prefixing each field name in a table with abbreviated table name a good practice?

I mentioned in my answer के रूप में; टेबल नाम के साथ उपनाम फ़ील्ड नामों की अवधारणा विरासत प्रणाली के पुराने समय से आता है जब पूरे डेटाबेस में प्रत्येक फ़ील्ड अद्वितीय होना आवश्यक होता है। आधुनिक प्रणालियों द्वारा इसकी आवश्यकता नहीं है, इसलिए यह सिर्फ एक सम्मेलन है जो अब आवश्यक नहीं है। Think Before Coding ने उल्लेख किया "तालिका नाम पहले से ही संदर्भ देता है। उपसर्ग कॉलम की आवश्यकता नहीं है इसके साथ ही नाम"

Answer 10

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

Answer 11

विकल्प 2 सबसे अच्छा है (मेरे लिए पाठ्यक्रम :)),
मैं एक PHP प्रोग्रामर नहीं हूं .NET एक।

Answer 12

मैं दूसरा विकल्प पसंद करता हूं क्योंकि मेरे लिए पहला विकल्प, अनावश्यक पुनरावृत्ति की तरह लगता है। बेशक, मैं मुख्य रूप से रेल प्रोग्रामर पर रूबी हूं, इसलिए मुझे DRY principle पसंद है। :) मुझे यह सी # प्रोग्रामिंग में परेशान पाया गया क्योंकि सबकुछ पहले, स्पष्ट-लेकिन-दोहराव वाले संस्करण का उपयोग करता है।