Який ефективний спосіб маркування стовпців у базі даних?

Я використовував позначення стовпців у своїх базах даних так:

user_id
user_name
user_password_hash

Щоб уникнути конфліктів при з'єднанні двох таблиць, але потім я дізнався більше про те, як псувати псевдоніми, і перестав це робити.

Який ефективний спосіб маркування стовпців у базі даних? Чому?

У вашому випадку користувач префікса зайвий. Ми (відповідальні розробники) знаємо, що це користувач таблиці, тому навіщо додавати user_префікс перед кожним полем?

Я б вам запропонував зробити це з більш природним підходом.

Які характеристики людини: Прізвище, ім’я, дата народження, громадянство тощо ...

Які характеристики автомобіля: модель, рік, колір, енергія тощо ...

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

Окрім коментаря Spredzy, позначте свої первинні ключі однаковими (ID), щоб, коли ви пишете запити під час руху, ви могли легко згадати (u.ID = c.ID), а не шукати "Чи було це CountryID , country_ID, country_ID, countryID,? "

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

Немає сенсу мати користувачів.user_id та cars.car_id, коли ви могли мати користувачів.id та cars.id

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

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

• Ви можете використовувати цей синтаксис об'єднання: a JOIN b USING (a_id) JOIN c USING (a_id). Дуже зручно і також допомагає наступний момент.

• Якщо ви запускаєте запити з великою кількістю приєднань або створюєте матеріалізовані представлення SELECT *, ви ніколи (добре, можливо, рідко) не матимете конфлікту. Подумайте про приєднання person.name, product.name, country.nameі т.д. Urgh.

• Взагалі, якщо у вас є великі запити, важко відстежувати, що idозначає всюди.

Подивимось, з вашим прикладом це буде виглядати приблизно так:

USERS
----
id
username,
password
registration_date

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

До речі, я думаю, ви повинні знайти якийсь стиль, який вам подобається, і дотримуватися його. Якщо ви часто змінюєте її, ви матимете схему БД Messier.

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

Нещодавно я покинув компанію, де один із розробників віддав перевагу приставці стовпців первинного ключа та стороннього ключа за допомогою pk та fk. Це призводить до деяких мерзот, коли стовпці починалися з pkfk (зазвичай це складений первинний ключ на основі 2 стовпців, з яких один стовпець був іноземним ключем до іншого таблиці).

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

В ідеалі назви стовпців унікальні для всіх таблиць бази даних.

Деякі спостереження:

• нам потрібні псевдоніми таблиць, коли таблиці об'єднуються кілька разів у операторі select
• це запобігає деяким помилкам при копіюванні фрагментів коду, оскільки назви стовпців повинні бути адаптовані до назви таблиці
• це допомагає показати, до якої таблиці вказується стовпчик іноземного ключа

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

Я погоджуюся з відповіддю Spredzy, але додав би, що в якості переваги я використовую camelCase замість under_score.

firstName, lastName тощо.

У разі Oracle, ви хочете , щоб НЕ назвати стовпці «ідентифікатор» або «ім'я» або що - небудь родове.

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

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

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

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

... і збереження набору тексту приводить нас до ще однієї проблеми в Oracle - принаймні до 8i (поточна версія, коли я брав курси настройки Oracle SQL Tuning та моделювання даних) кешування планів виконання засноване на перших стільки символах запит (не можете згадати точне значення ... 1024?), тож якщо у вас є запити, які змінюються лише чим-небудь до кінця пункту де, і дійсно довгий список стовпців, які ви виймаєте, ви може зіткнутися з хітом продуктивності, оскільки він не може правильно кешувати план виконання.

У Oracle було керівництво по вибору того, що вони стверджують, що це гарні назви таблиць і стовпців, що в основному є посібником для видалення букв, поки це приблизно 5-8 символів, але я ніколи не дуже переймався цим.

...

Як інакше:

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

оновлення : для тих, хто не знайомий з поведінкою приєднання Oracle, перегляньте останній приклад з Mastering Oracle SQL: Умови приєднання , де він згадує:

Що сталося? Причина полягає в тому, що крім постачальника_id, ці дві таблиці мають ще одну пару стовпців із загальною назвою. Цей стовпець - ім'я. Отже, коли ви запитуєте про природне з'єднання між постачальником і таблицями частин, з'єднання відбувається не тільки шляхом прирівнювання стовпця_в_допоміж двох таблиць, але і стовпця імен з двох таблиць прирівнюється також. Оскільки жодне ім’я постачальника не збігається з назвою частини цього ж постачальника, запит не повертає жодних рядків.

У розділі "старий синтаксис приєднання" (8i та новіші версії) "NATURAL JOIN" був типовим поведінкою приєднання, і я вважаю, що це все ще є, якщо ви не вказали умову приєднання. Після того, як "НАТУРАЛЬНИЙ ПРИЄДНАЙТЕСЬ" був офіційним варіантом у 9i, загальна рекомендація не використовувати його , тому що неправильне іменування стовпців може вас накрутити, що, на мою думку, я виступаю за гарні назви стовпців.

1. Ніколи не використовуйте подвійні лапки, "тому що ви переосмислюєте власне складання баз даних. Специфікація SQL вимагає, щоб усі ідентифікатори були складені у верхній регістр. Деякі бази даних, наприклад PostgreSQL, складають їх у малі регістри. Якщо нічого не цитується, воно буде працювати у всіх базах даних, і вони можуть скласти їх на специфікацію або специфічну для rdbms за замовчуванням.
2. Використовуйте under_score ( _), оскільки, як зазначено вище, не слід використовувати camelCase.

3. використовувати {entity}_idдля ідентифікаторів (і зовнішніх ключів, що вказують на ці ідентифікатори). Тому що тоді ви можете скористатись USINGпунктом. Унікальні глобальні ключові імена, що використовуються в умовах приєднання, є умовою, встановленою в специфікації.

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