Чому префіксація назв стовпців вважається поганою практикою?

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

Все, що я знаю, - читати AdventureWorks набагато простіше. У цьому БД нашої компанії ви побачите таблицю, Person і вона може мати назву стовпця:

Person_First_Name
або, можливо, навіть
Person_Person_First_Name (не питайте мене, чому ви бачите особу 2x)

Чому вважається поганою практикою попередньо виправляти назви стовпців? Чи підкреслення вважається злом і в SQL?

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

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

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

Аргументом префіксації імені стовпця буде запобігання імені "зіткнення" під час об'єднання декількох таблиць ТА, коли творець запиту не використовує псевдоніми.

SELECT person.name, company.name FROM person JOIN company ON ...

SELECT * FROM person JOIN company ON ...

Обидва запити матимуть два стовпці "ім'я" ( ім'я_1, ім'я_2 ), не "повідомляючи", якій суті належить. І ви ніколи не можете бути впевнені у створених іменах стовпців (це буде ім’я_2 чи ім’я_3 чи ...). Якщо ви використовуєте префікс імені таблиці, імена стовпців будуть іменем особи , company_name так що ви знаєте , кожне ім'я , до якого вона належить об'єкту, плюс ви знаєте , що імена стовпців залишатимуться постійними (якщо ви отримуєте їх в Java з використанням JDBC, наприклад , ).

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

Що стосується підкреслення в назвах таблиць та стовпців, то я його широко використовую, оскільки в якості розділювача я використовую лише малі регістри та підкреслення. Використання лише малих літер допомагає відрізнити ідентифікатори від ключових слів SQL (які я набираю у всіх великих літерах):

SELECT person_name, COUNT(bought_product) FROM bought_products WHERE person_name LIKE 'A%'

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

Є винятки, якщо їх застосовувати розумно (відповідно до відповіді Патріка Карчера на вашому посиланні) для загальних імен стовпців (як правило, лише ідентифікатор, іноді Ім'я), які були б неоднозначними занадто часто .

Ще одна найкраща практика - це завжди кваліфікувати стовпці та об’єкти у ваших запитах. Тож префікси стовпців стають суперечливими та захаращують ваш код.

Порівняйте ці: що найпростіше на око?

SELECT P.name, P.Salary FROM dbo.Person P

SELECT Person.Name, Person.Salary FROM dbo.Person Person

SELECT dbo.Person.name, dbo.Person.Salary FROM dbo.Person

SELECT Person.Person_name, Person.Person_Salary FROM dbo.Person Person

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

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

У TSQL ви можете посилатися на поля у формі TableName.FieldName, якщо ви хочете уникнути двозначності, тому додавання імен таблиць до імен полів насправді забирає читабельність, роблячи її TableName.TableName_FieldName або подібне. Я думаю, використовувати підкреслення чи ні - це більше особистий вибір. Я віддаю перевагу CamelCase, і я використовую _, коли хочу додати суфікс або подібне, наприклад, TableName_Temp, але це тільки я.

Я колись працював над системою, де ми вирішили використовувати короткі коди для префіксації стовпців. У полях ПК використовувались як префікс "ім'я повної таблиці", а всі інші стовпці послідовно використовували 2-4 символи як свій префікс. Кожен стовпець також використовував домен даних як свій суфікс. Якщо робити це послідовно, це може бути дуже приємно і чисто. Дурниця, що стандарт іменування того чи іншого типу позначає неохайне кодування. Важливим є наявність послідовного стандарту. Я бачив низку баз даних, які є непослідовними, оскільки немає чіткого стандарту, і що більше, ніж усе інше вказувало б мені на те, що в структурах даних можуть виникнути проблеми. Якщо дизайнер бази даних навіть не може послідовно називати об'єкти та їх дітей,

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

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

Багато баз даних мають чіткі обмеження щодо кількості символів у назві стовпця (тобто Oracle).

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

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

Подумайте про написання словника даних (або "реєстру"). Під цим я маю на увазі документ, що містить усі елементи даних у вашій моделі: ім'я, опис тощо. Він повинен бути незалежним від реалізації моделі, наприклад, не повинен згадувати назви таблиць. Як би ви не розмежовували імена, такі як "ID", "Тип" та "Код"?

Один із підходів полягає у дотриманні вказівок міжнародного стандарту ISO / IEC 11179 - зрештою, навіщо винаходити колесо? Основна структура:

[Object] [Qualifier] Property RepresentationTerm

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

У мене є відчуття, що хтось у вашій організації намагався дотримуватися цих вказівок, коли вони придумали такі назви елементів, як Person_Person_First_Name.

Приклад, який я хочу показати, - це словник даних служби охорони здоров’я Великобританії (NHS) .

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

У реалізації , наприклад , в SQL, деякі народні , як опустити об'єкт, Класифікатор і власності суб-елементи , коли ім'я таблиці забезпечує контекст , наприклад , person_first_nameстає first_nameв Personтаблиці і т.д. Однак, емпіричне правило , що елемент даних не повинен змінити свою назву просто завдяки своєму розташуванню у фізичній моделі здається хорошим. Кожен, хто вважає, що дотримуватись цього правила не годиться, слід доручити документувати всі варіанти імен, які вони використовували :)

Ви знайдете хороший підсумок ISO 11179 у книзі Програмування стилю Джо Челко , включаючи докази того, що в назвах стовпців перевага підкреслюють як роздільники.

Декому в коді простіше дізнатись, з якої таблиці отримані дані, однак, якщо ви говорите про об'єктно-орієнтовану систему, вам слід використовувати контекст імені, щоб знати, звідки вони прийшли, в даному випадку - ім’я таблиці.

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