Присвоєння імені стовпців ідентифікаторів у таблицях баз даних

Мені цікаво було думки людей щодо іменування стовпців ідентифікаторів у таблицях баз даних.

Якщо у мене є таблиця "Рахунки-фактури" з первинним ключем стовпця ідентифікатора, я б назвав цей стовпець "InvoiceID", щоб я не конфліктував з іншими таблицями, і очевидно, що це таке.

Там, де я працюю поточним, вони називають усі стовпці ідентифікатора ID.

Тому вони робили б наступне:

Select  
    i.ID 
,   il.ID 
From
    Invoices i
    Left Join InvoiceLines il
        on i.ID = il.InvoiceID

Тепер я бачу тут кілька проблем:
1. Вам потрібно буде встановити псевдонім стовпців на select
2. ID = InvoiceID не міститься в моєму мозку
3. Якщо ви не зробили псевдонім таблиць і посилалися на InvoiceID, очевидно, яка таблиця це включено?

Які думки інших людей щодо цієї теми?

Ідентифікатор - це SQL-шаблон. Див. Http://www.amazon.com/s/ref=nb_sb_ss_i_1_5?url=search-alias%3Dstripbooks&field-keywords=sql+antipatterns&sprefix=sql+a

Якщо у вас багато таблиць з ідентифікатором як ідентифікатор, ви значно ускладнюєте звітування. Це затемнює сенс і ускладнює читання складних запитів, а також вимагає використання псевдонімів для розрізнення самого звіту.

Крім того, якщо хтось досить дурний, щоб використовувати природне об’єднання в базі даних, де вона доступна, ви приєднаєтесь до неправильних записів.

Якщо ви хочете використовувати синтаксис USING, який дозволяють деякі бази даних, ви не можете, якщо ви використовуєте ID.

Якщо ви використовуєте ідентифікатор, ви можете легко отримати помилкове приєднання, якщо випадково копіюєте синтаксис приєднання (не кажіть мені, що ніхто ніколи цього не робить!) І забудьте змінити псевдонім в умові приєднання.

Отже, тепер у вас є

select t1.field1, t2.field2, t3.field3
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t1.id = t3.table2id

коли ви мали на увазі

select t1.field1, t2.field2, t3.field3 
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t2.id = t3.table2id

Якщо ви використовуєте tablenameID як поле ідентифікатора, така випадкова помилка набагато рідше трапляється і набагато легше знайти.

Я завжди віддавав перевагу ідентифікатору TableName + ID для стовпця id, а потім TableName + ID для зовнішнього ключа. Таким чином, усі таблиці мають однакове ім'я для поля id, і немає зайвого опису. Мені це здається простішим, оскільки всі таблиці мають однакове ім'я поля первинного ключа.

Що стосується об’єднання таблиць та невідомості, яке поле Id до якої таблиці належить, на мій погляд, запит повинен бути написаний для вирішення цієї ситуації. Там, де я працюю, ми завжди надаємо перевагу полям, які ми використовуємо в операторі, з псевдонімом таблиці / таблиці.

У моїй компанії останнім часом у цій компанії були ботанічні бої. Поява LINQ зробило надмірне ім’я таблиці + шаблон ідентифікатора ще більш очевидним на мої очі. Я думаю, що більшість розумних людей скажуть, що якщо ви пишете свій SQL таким чином, що вам потрібно вказати імена таблиць, щоб диференціювати FK, це не тільки економія на введенні, але це додає ясності вашому SQL для використання просто ідентифікатор, завдяки якому ви можете чітко бачити, що є ПК, а що - ФК .

Напр

ВІД Співробітників e ЛІВО ПРИЄДНАЙТЕСЬ до клієнтів c ON e.ID = c.E EmployeeID

говорить мені не тільки про те, що вони пов’язані між собою, але що є ПК, а що - ФК . Тоді як за старим стилем ви змушені або виглядати, або сподіватися, що їх добре назвали.

Ми використовуємо InvoiceID, ні ID. Це робить запити більш читабельними - коли ви бачите IDпоодинці, це може означати що завгодно, особливо коли ви використовуєте псевдонім таблиці i.

Я погоджуюся з Кевеном та кількома іншими людьми тут, що ПК для таблиці повинен бути просто ідентифікатором, а зовнішні ключі перелічують OtherTable + Id.

Однак я хотів би додати одну причину, яка нещодавно додала більшої ваги цій аргументації.

На моєму теперішньому становищі ми використовуємо структуру сутності, використовуючи генерацію POCO. Використовуючи стандартну конвенцію іменування Id, PK дозволяє успадкувати базовий клас poco з валідацією та такий для таблиць, що мають спільний набір загальних імен стовпців. Використання Tablename + Id як PK для кожної з цих таблиць руйнує можливість використання базового класу для них.

Лише трохи їжі для роздумів.

Моїм уподобанням є також ідентифікатор первинного ключа та TableNameID для зовнішнього ключа. Мені також подобається мати стовпець "ім'я" у більшості таблиць, де я зберігаю зручний для читання ідентифікатор (тобто ім'я :-)) запису. Ця структура пропонує велику гнучкість у самому додатку, я можу обробляти таблиці масово, так само. Це дуже потужна річ. Зазвичай програмне забезпечення OO будується поверх бази даних, але набір інструментів OO не може бути застосований, оскільки сам db цього не дозволяє. Наявність ідентифікатора та імені стовпців все ще не дуже добре, але це крок.

Виберіть
i.ID, il.ID із рахунків-фактур, які я зліва приєднав InvoiceLines il на i.ID = il.InvoiceID

Чому я не можу це робити?

Select  
    Invoices.ID 
,   InvoiceLines.ID 
From
    Invoices
    Left Join InvoiceLines
        on Invoices.ID = InvoiceLines.InvoiceID

На мій погляд, це дуже читабельно та просто. Іменування змінних як i та il взагалі є поганим вибором.

Це насправді не важливо, ви, ймовірно, зіткнетеся з проблемами сималярності у всіх конвенціях імен.

Але важливо бути послідовним, щоб вам не потрібно було переглядати визначення таблиць кожного разу, коли ви пишете запит.

Я щойно почав працювати в місці, яке використовує лише "ID" (у основних таблицях, на які посилається TableNameID у зовнішніх ключах), і вже знайшов ДВІ виробничі проблеми, безпосередньо спричинені цим.

В одному випадку в запиті було використано "... where ID in (SELECT ID FROM OtherTable ..." замість "... where ID in (SELECT TransID FROM OtherTable ...".

Хтось може чесно сказати, що не було б набагато простіше виявити, якби використовувались повні, послідовні імена, де неправильний вислів міг би читати "... де TransID в (SELECT OtherTableID з OtherTable ..."? Я не думаю так.

Інша проблема виникає при рефакторингу коду. Якщо ви використовуєте тимчасову таблицю, тоді як раніше запит виходив із базової таблиці, тоді старий код читає "... dbo.MyFunction (t.ID) ...", і якщо це не змінено, але "t" тепер посилається на temp замість таблиці core, ви навіть не отримуєте помилку - просто помилкові результати.

Якщо генерування непотрібних помилок є метою (можливо, деяким людям не вистачає роботи?), То такий тип дотримання імен є чудовим. В іншому випадку послідовне іменування - це шлях.

Для простоти більшість людей називають стовпець в ідентифікаторі таблиці. Якщо він має посилання на зовнішній ключ в іншій таблиці, тоді вони називають його InvoiceID (на прикладі вашого прикладу) у випадку об'єднань, ви все одно псевдонізуєте таблицю, тому явний inv.ID все ще простіший ніж inv.InvoiceID

Я особисто віддаю перевагу (як уже було сказано вище) Table.ID для ПК і TableID для FK . Навіть (будь ласка, не стріляйте в мене) Microsoft Access рекомендує це.

Втім, я ТАКЖЕ знаю, що деякі засоби генерації надають перевагу TableID для PK, оскільки вони, як правило, пов'язують усі назви стовпців, що містять "ID" у слові, Включаючи ID !!!

Навіть дизайнер запитів робить це на Microsoft SQL Server (і для кожного створеного вами запиту ви в кінцевому підсумку вириваєте всі непотрібні новостворені зв'язки з усіх таблиць в ідентифікаторі стовпця)

ОТО, наскільки мій внутрішній OCD ненавидить це, я погоджуюсь з умовою TableID . Давайте пам’ятатимемо, що це називається БАЗА даних , оскільки вона буде базою для багатьох, багато надійних додатків. І всі технології повинні мати вигоду від добре нормалізованої з чітким описом схеми.

Само собою зрозуміло, що я РЕШУЮ свою чергу, коли люди починають використовувати TableName, TableDescription тощо. На мій погляд, конвенції повинні робити наступне:

• Назва таблиці: Множинне. Вих. Співробітники

• Псевдонім таблиці: Повна назва таблиці, однина. Вих.

  SELECT Employee.*, eMail.Address
  FROM Employees AS Employee LEFT JOIN eMails as eMail on Employee.eMailID = eMail.eMailID -- I would sure like it to just have the eMail.ID here.... but oh well

[Оновлення]

Крім того, у цій темі є кілька дійсних публікацій про дубльовані стовпці через "тип відносин" або роль. Наприклад, якщо в магазині є EmployeeID , це говорить мені присідання. Тому я іноді роблю щось на зразок Store.EfficieeID_Manager . Звичайно, він трохи більший, але, по крайней мере, люди не зійдуть з розуму, намагаючись знайти таблицю ManagerID або те , що там робить EmployeeID . Коли запит ДЕ, я б спростив його як: ВИБЕРІТЬ EmployeeID_Manager як ManagerID FROM Store

Розглядаючи це з точки зору офіційного словника даних, я б назвав елемент даних invoice_ID. Як правило, ім'я елемента даних буде унікальним у словнику даних і в ідеалі матиме одне й те саме ім'я протягом усього часу, хоча іноді можуть вимагатися додаткові кваліфікаційні терміни на основі контексту, наприклад, названий елемент даних employee_IDможе використовуватися двічі в організаційній діаграмі і, отже, кваліфікується як supervisor_employee_IDі subordinate_employee_IDвідповідно.

Очевидно, що умовні принципи іменування є суб’єктивними та мають значення стилю. Я вважаю керівні принципи ISO / IEC 11179 корисною відправною точкою.

Що стосується СУБД, я бачу таблиці як колекції entites (за винятком тих, які коли-небудь містять лише один рядок, наприклад, таблиця cofig, таблиця констант тощо), наприклад таблиця, де мій employee_IDключ, буде названа Personnel. Тож відразу TableNameIDконвенція для мене не працює.

Я бачив TableName.ID=PK TableNameID=FKстиль, який використовується у великих моделях даних, і маю сказати, я вважаю його трохи заплутаним: я набагато більше люблю, щоб ім'я ідентифікатора було однаковим, тобто не змінювало ім'я залежно від таблиці, в якій воно трапляється. Щось, на що слід звернути увагу вищезгаданий стиль, здається, використовується в магазинах, які додають стовпець IDENTITY(автоматичне збільшення) до кожної таблиці, одночасно уникаючи природних та складених ключів у зовнішніх ключах. Ці магазини, як правило, не мають офіційних словників даних і не будують на основі моделей даних. Знову ж таки, це лише питання стилю і питання, на яке я особисто не підписуюсь. Тож, зрештою, це не для мене.

З усього сказаного, я бачу випадок, коли іноді випадає кваліфікатор з імені стовпця, коли ім'я таблиці надає контекст для цього, наприклад, названий елемент employee_last_nameможе стати просто last_nameв Personnelтаблиці. Обгрунтування тут полягає в тому, що домен є "прізвищами людей" і, швидше за все, він буде UNIONредагуватися за допомогою last_nameстовпців з інших таблиць, а не використовуватись як зовнішній ключ в іншій таблиці, але знову ж таки ... Я міг би просто передумати, іноді ви ніколи не можете сказати. Ось у чому річ: моделювання даних - це частково мистецтво, частково наука.

Я думаю, ви можете використовувати будь-що для "посвідчення особи", якщо ви послідовні. Включення назви таблиці важливо. Я б запропонував використовувати інструмент моделювання, такий як Erwin, щоб забезпечити дотримання іменних норм та стандартів, тому під час написання запитів легко зрозуміти взаємозв'язки, які можуть існувати між таблицями.

Що я маю на увазі під першим твердженням, замість ідентифікатора ви можете використовувати щось інше, як "recno". Тоді в цій таблиці буде PK рахунку_фактури_речно тощо.

Ура, Бен

Я голосую за InvoiceID за ідентифікатор таблиці. Я також використовую ту саму конвенцію іменування, коли вона використовується як зовнішній ключ, і використовую інтелектуальні псевдоніми в запитах.

 Select Invoice.InvoiceID, Lines.InvoiceLine, Customer.OrgName
 From Invoices Invoice
 Join InvoiceLines Lines on Lines.InvoiceID = Invoice.InvoiceID
 Join Customers Customer on Customer.CustomerID = Invoice.CustomerID

Звичайно, це довше, ніж деякі інші приклади. Але посміхніться. Це для нащадків, і коли-небудь якомусь бідному молодшому кодеру доведеться змінити ваш шедевр. У цьому прикладі немає двозначності, і якщо до запиту додаються додаткові таблиці, ви будете вдячні за детальність.

Для імені стовпця в базі даних я б використовував "InvoiceID".

Якщо я скопіюю поля в безіменну структуру через LINQ, я можу назвати його "ID" там, якщо це єдиний ідентифікатор у структурі.

Якщо стовпець НЕ буде використовуватися в зовнішньому ключі, тому він використовується лише для однозначної ідентифікації рядка для редагування або видалення, я буду називати його "PK".

Якщо ви даєте кожному ключу унікальне ім'я, наприклад "invoices.invoice_id" замість "invoices.id", тоді ви можете без зайвих проблем використовувати оператори "natural join" та "using". Напр

SELECT * FROM invoices NATURAL JOIN invoice_lines
SELECT * FROM invoices JOIN invoice_lines USING (invoice_id)

замість

SELECT * from invoices JOIN invoice_lines
    ON invoices.id = invoice_lines.invoice_id

SQL достатньо багатослівний, не роблячи його більш багатослівним.

Що я роблю, щоб зберегти послідовність для себе (де в таблиці є первинний ключ із одним стовпцем, що використовується як ідентифікатор), - це називати первинний ключ таблиці Table_pk. У будь-якому місці зовнішнього ключа, який вказує на первинний ключ цієї таблиці, я називаю стовпець PrimaryKeyTable_fk. Таким чином, я знаю, що якщо у мене є Customer_pkтаблиця Замовників та таблиця Customer_fkЗамовлення, я знаю, що таблиця Замовлення посилається на запис у таблиці Замовників.

Для мене це має сенс особливо для об'єднань, де, на мою думку, це читається легше.

SELECT * 
FROM Customer AS c
    INNER JOIN Order AS c ON c.Customer_pk = o.Customer_fk

FWIW, наш новий стандарт (який змінюється, я маю на увазі "еволюціонує", з кожним новим проектом):

• Назви полів бази даних нижнього регістру
• Великі назви таблиць
• Використовуйте символи підкреслення, щоб відокремити слова в назві поля - перетворіть їх у регістр Pascal у коді.
• pk_ префікс означає первинний ключ
• _id суфікс означає ціле число, ідентифікатор з автоматичним збільшенням
• fk_ префікс означає зовнішній ключ (суфікс не потрібен)
• _VW суфікс для переглядів
• is_ префікс для логічних типів

Отже, таблиця з іменем NAMES може мати поля pk_name_id, first_name, last_name, is_alive,та fk_companyі вигляд із викликом LIVING_CUSTOMERS_VW, визначений як:

ВИБЕРІть ім'я, прізвище
ВІД КОНТАКТУ.ІМЕНИ
ДЕ (is_alive = 'True')

Однак, як казали інші, майже будь-яка схема буде працювати, доки вона буде послідовною і не буде зайвим чином затьмарювати ваші значення.

Я точно погоджуюсь із включенням назви таблиці в назву поля ідентифікатора, саме з тих причин, які ви вказали. Як правило, це єдине поле, куди я б включив назву таблиці.

Я ненавиджу просто ім'я ідентифікатора. Я настійно вважаю за краще завжди використовувати invoice_id або його варіант. Я завжди знаю, яка таблиця є авторитетною таблицею для ідентифікатора, коли мені це потрібно, але це мене бентежить

SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceID = inv.ID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceLineID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceLineID = inv.ID 

Найгірше за все - це мікс, про який ви згадуєте, абсолютно заплутаний. Мені доводилося працювати з базою даних, де майже завжди це був foo_id, за винятком одного з найбільш використовуваних ідентифікаторів. Це було повне пекло.

Я віддаю перевагу DomainName || 'ID'. (тобто DomainName + ID)

Ім'я домену часто, але не завжди, збігається з іменем таблиці.

Проблема ідентифікатора сама по собі полягає в тому, що він не масштабується вгору. Коли у вас є близько 200 таблиць, кожна з яких має перший стовпець з ідентифікатором, дані починають виглядати однаково. Якщо ви завжди відповідаєте ідентифікатору з назвою таблиці, це трохи допомагає, але не так сильно.

Ім'я домену та ідентифікатор можна використовувати для іменування зовнішніх ключів, а також первинних ключів. Коли зовнішні ключі названі після стовпця, на який вони посилаються, це може бути мнемонічною допомогою. Формально прив'язувати ім'я зовнішнього ключа до ключа, на який він посилається, не потрібно, оскільки обмеження цілісності посилань встановлюватиме посилання. Але це дуже зручно, коли справа стосується читання запитів та оновлень.

Іноді DomainName || "Ідентифікатор" не можна використовувати, оскільки в одній таблиці буде два стовпці з однаковою назвою. Приклад: Employees.E EmployeeID і Employees.SupervisorID. У цих випадках я використовую RoleName || 'ID', як у прикладі.

І останнє, але не менш важливе: я використовую природні, а не синтетичні ключі, коли це можливо. Бувають ситуації, коли природні ключі недоступні або не заслуговують на довіру, але є багато ситуацій, коли природний ключ є правильним вибором. У цих випадках я дозволяю природному ключу прийняти назву, яку він би, природно, мав. У цій назві часто навіть немає букв "ID". Приклад: OrderNo, де No - це абревіатура для "Number".

Для кожної таблиці я вибираю скорочену букву дерева (наприклад, працівники => Emp)

Таким чином числовий первинний ключ із автоматичним числом стає nkEmp .

Він короткий, унікальний у всій базі даних, і я точно знаю його властивості з першого погляду.

Я зберігаю однакові імена в SQL та всіх мовах, якими я користуюся (переважно C #, Javascript, VB6).

Перегляньте конвенції щодо іменування на сайті Інтеракт для продуманої системи іменування таблиць та стовпців. Метод використовує суфікс для кожної таблиці ( _prdдля таблиці товарів або _ctgдля таблиці категорій) і додає його до кожного стовпця в даній таблиці. Отже, стовпець ідентифікації для таблиці товарів буде id_prdі тому є унікальним у базі даних.

Вони роблять ще один крок далі, щоб допомогти зрозуміти зовнішні ключі: Зовнішній ключ у таблиці продуктів, який посилається на таблицю категорій, буде idctg_prdтаким, щоб було очевидно, до якої таблиці він належить ( _prdсуфікс), а до якої таблиці він посилається (категорія) .

Переваги полягають у тому, що у стовпцях ідентичності в різних таблицях немає однозначності, і що ви можете швидко зрозуміти, на які стовпці посилається запит за іменами стовпців.

також див. Конвенцію щодо іменування первинного ключа / зовнішнього ключа

Ви можете скористатися наведеною нижче умовою іменування. У нього є свої недоліки, але він вирішує ваші конкретні проблеми.

1. Використовуйте короткі (3-4 символи) псевдоніми для назв таблиць, тобто Invoice - inv, InvoiceLines -invl
2. Назвіть стовпці в таблиці , використовуючи ці прізвиська, тобто inv_id,invl_id
3. Для довідкових стовпців використовуйте invl_inv_idдля імен.

таким чином можна сказати

SELECT * FROM Invoice LEFT JOIN InvoiceLines ON inv_id = invl_inv_id