Чи існує угода про іменування для MySQL?

163

Ось як я це роблю:

Імена таблиць в нижньому регістрі, використовує підкреслення для поділу слів, і є особливими (наприклад foo, foo_barі т.д.
У мене зазвичай (не завжди) є автоматичний приріст ПК. Я використовую наступну угоду: tablename_id(наприклад foo_id, foo_bar_idі т.д.).
Коли таблиця містить стовпчик, який є іноземним ключем, я просто копіюю ім'я стовпця цього ключа з тієї таблиці, з якої він вийшов. Наприклад, таблиця сказати foo_barмає FK foo_id(де foo_idPK of foo).
Визначаючи FKs для забезпечення референтної цілісності, я використовую таке: tablename_fk_columnname(наприклад, подальший приклад 3, це було б foo_bar_foo_id). Оскільки це комбінація імені таблиці / імені стовпця, воно гарантовано буде унікальним у базі даних.
Я впорядковую стовпчики так: ПК, FK, потім решта стовпців за алфавітом

Чи є кращий, більш стандартний спосіб зробити це?

mysql naming-conventions mysql-workbench

6

Чи неправильно використовувати для автоматичного збільшення ПК просто "id"? Чому? Назва стовпця має значення лише в контексті таблиці. Таким чином, у мене є один "id" у кожній таблиці, і може бути багато id_ <table_name> для FK.

— Збишек

3

@Zbyszek Я думаю, що найпростіша причина проти цього - просто послідовність / простота. Замість того, щоб мати id_tableB=> ой не стовпчик з різними назвами id , консистенція id_tableB=> id_tableBпросто виглядає акуратніше ... або як це робить ОП: foo_id=> foo_idа не foo_id=>id

— Дон Чейдл,

106

Я б сказав, що перш за все: будьте послідовними.

Я вважаю, що ви майже там з умовами, які ви окреслили у своєму питанні. Кілька коментарів, хоча:

Бали 1 і 2 - це добре, я вважаю.

Пункт 3 - на жаль, це не завжди можливо. Подумайте, як би ви впоралися з однією таблицею, foo_barяка містить стовпці, foo_idі another_foo_idобидва посилаються на стовпчик fooтаблиці foo_id. Ви можете подумати, як з цим боротися. Це трохи кутовий випадок, хоча!

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

Пункт 5 - Я б цього уникнув. Це забезпечить вам мало і стане головним болем, коли ви хочете пізніше додати або видалити стовпці з таблиці.

Деякі інші моменти:

Індексні імена конвенцій

Ви можете запровадити конвенцію про іменування індексів - це буде чудовою підмогою для будь-яких робіт з метаданими бази даних, які ви могли б хотіти виконати. Наприклад, ви можете просто подзвонити в індекс foo_bar_idx1або foo_idx1- повністю залежить від вас, але варто розглянути.

Сингулярні і множинні назви стовпців

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

Головне тут, звичайно, послідовність!

— Том Мак
джерело

Що було б краще, ніж точка 5? Чому це може стати головним болем?

— Рашу

7

Щоб продовжити, я знайшов цю версію корисною для тих, хто приїде сюди пізніше: launchbylunch.com/posts/2014/Feb/16/sql-naming-conventions/…

— Enissay

1

У мене виникають проблеми з пошуку хорошої «схеми» для назви моїх таблиць, в яких є об’єкти моделей, що складаються з двох імен (DocumentChapter, DocumentVersion, DocumentType тощо). Наприклад, для DocumentType я міг назвати його documenttypeабо document_type. Я вважаю за краще останній, але більшу частину часу я маю багато-багато стосунків, і мені потрібна таблиця, схожа document_document_type. Будь-які пропозиції, як впоратися з цим?

— лексит

@ rsb2097 Re: пункт 5 - Після додавання одного стовпця (до кінця) замовлення може стати недійсним. Не слід додавати жодних обмежень, які потребують переупорядкування стовпців, оскільки це зайві накладні витрати.

— Буде Шеппард

21

Послідовність - це ключ до будь-якого стандарту іменування. Поки це логічно і послідовно, ви там на 99%.

Сам стандарт є дуже особистим уподобанням - тому, якщо вам подобається ваш стандарт, тоді працюйте з ним.

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

— маль-ван
джерело

8

У MySQL є короткий опис їх більш-менш суворих правил:

https://dev.mysql.com/doc/internals/en/coding-style.html

Найпоширеніший стиль кодування для MySQL від Simon Holywell:

http://www.sqlstyle.guide/

Дивіться також це питання: Чи є опубліковані вказівки щодо стилю кодування для SQL?

— Даніель В.
джерело

4

На щастя, розробники PHP не є "фатографами верблюда", як деякі спільноти розвитку, яких я знаю.

Ваші умовності звучать чудово.

До тих пір, поки вони а) прості та б) послідовні - я не бачу жодних проблем :)

PS: Особисто я думаю, 5) є надмірним ...

— паульсм4
джерело

2

Справа на верблюдах, далеко не як фанатиків, насправді нахмурюється багатьма спільнотами БД, оскільки деякі RDBMS 'нечутливі до тих випадків, коли вони знімуть справи (або змінить все на верхній регістр), так що речі стають справді некрасивими дуже швидко.

— mal-wan

@mwan: чи можете ви вказати, який RDBMS '? І я сам жекей верблюда. Шапки служать лише одній цілі в моїй схемі - вказувати таблиці приєднання та (у випадку з полями) вказувати межі слів, так що _ може бути виключно для вказівки на іншу таблицю_id (тобто назва таблиці = othertable та поле в цій таблиці = id ). Крім того, якщо інші RDBMS не чутливі до регістру, що це насправді має значення? Я ніколи не збираюся мати верхні та малі версії тієї ж таблиці! О, і я б не вважав за краще RDBMS, що не враховує регістр - я б краще писав послідовний код

— Samuel Fullman

7

Мені подобається іронія того, що користувачі MySQL не люблять CamelCase та назва продукту, який ми використовуємо: MySQL, написаний на CamelCase

— DBX12

1

@ DBX12 Щоб бути педантичним, це PascalCase, а не camelCase, але ваша думка все ще стоїть.

— MarredCheese

@MarredCheese Ніколи про це не думав, але ти маєш рацію. camelCase не повинен мати горбка на початку.

— DBX12,

1

Проста відповідь: НІ

Ну, принаймні конвенція про іменування як така, яку заохочує Oracle або спільнота, але, в основному, ви повинні бути обізнані про дотримання правил і обмежень для ідентифікаторів, таких як зазначено в документації на MySQL: https://dev.mysql.com /doc/refman/8.0/en/identifiers.html

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

На особистому досвіді я б сказав це:

Використовуйте малі регістри . Це майже забезпечує взаємодію при переміщенні ваших баз даних з одного сервера на інший. Іноді lower_case_table_namesнеправильно налаштовано, і ваш сервер починає видавати помилки, просто розпізнаючи ваш стандарт camelCase або PascalCase (проблема чутливості випадку).
Короткі імена . Простий і зрозумілий. Найпростіше і швидше визначити свою таблицю або стовпці, тим краще. Повірте мені, коли ви робите багато різних запитів за короткий проміжок часу, краще мати всі прості для запису (і читання).
Уникайте префіксів . Якщо ви не використовуєте ту саму базу даних для таблиць різних програм, не використовуйте префікси. Це лише додасть більше деталізації вашим запитам. Бувають ситуації, коли це може бути корисним, наприклад, коли ви хочете ідентифікувати первинні та зовнішні ключі, зазвичай імена таблиць використовуються як префікс для стовпців id.
Використовуйте підкреслення для розділення слів . Якщо ви все ще хочете використовувати більше одного слова для іменування таблиці, стовпця тощо, тому використовуйте підкреслення для розділення_the_words , це сприяє розбірливості (ваші очі та ваш напружений мозок збираються дякувати).
Будьте послідовними . Як тільки у вас є власний стандарт, дотримуйтесь його. Не будьте людиною, яка створює правила, і це перша, яка їх порушує, це ганебно.

А як щодо називання "Множина проти однини"? Ну, це найбільше ситуація з особистими уподобаннями. У моєму випадку я намагаюся використовувати множинні назви для таблиць, тому що я вважаю, що таблиця є сукупністю елементів або пакетом, що містить елементи, тому ім'я множини має для мене сенс; і особливі назви стовпців, оскільки я бачу стовпчики як атрибути, які описують сингулярно ці елементи таблиці.

— Фабріціо Валенсія
джерело