Чи є причина використовувати вкрай скорочені назви таблиць?

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

Назви таблиць на зразок aptrx (операції з оплати рахунків) та apmaster_all (цікаво, що це таблиця постачальників). Це надзвичайно складна база даних, тому мені було цікаво, чи є якась логіка до конвенції, чи це просто затуманено навмисно чи іншим чином.

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

У Oracle було давно обмежене обмеження назви таблиць у 30 символів. Я підозрюю, що це застаріла проблема, заснована на оригінальному 16-бітному середовищі.
Довжина імені таблиці може мати певний мізерний ефект на продуктивність, оскільки всі імена мають бути збережені в словнику даних, а також розібрані для запитів, але я не думаю, що ви могли б виміряти звернення.

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

Я відчуваю, що є ще дві речі, які ще потрібно сказати або розробити:

1. Називати речі не так банально, як це звучить

   У комп’ютерній науці є лише дві важкі проблеми: недійсність кешу та іменування речей. Філ Карлтон

2. Хоча короткі безглузді імена завжди погані, довгі імена не завжди хороші - у наших мізків є вбудований tl; поріг dr, який дивно низький. 30 символів зазвичай достатньо, але я вважаю за краще RDBMS, щоб дозволити більше для виняткових випадків, коли цього немає (і як і в мові, довші імена корисніші для речей, про які ми не так часто говоримо - як імена обмежень, і короткі назви корисніші для таблиць, які ми постійно запитуємо)

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

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

Назви таблиць на зразок aptrx (операції з оплати рахунків) та apmaster_all (цікаво, що це таблиця постачальників). Це надзвичайно складна база даних, тому мені було цікаво, чи є якась логіка до конвенції, чи це просто затуманено навмисно чи іншим чином.

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

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

Скорочення зазвичай полегшують імена таблиць та назви стовпців, якщо скорочення виконано добре. Якщо я працював над кодом для AP цілий день, я б краще прочитав назви стовпців типу "ap_trx.inv_num", аніж "account_payable_transaction.invoice_number". (Мені подобаються підкреслення.) Введення довгих імен не є великою проблемою з хорошим текстовим редактором.

У системах бухгалтерського обліку і "ap", і "trx" є відомими абревіатурами. До інших належать "ar", "gl" та "gj" для дебіторської заборгованості, головної книги та загального журналу.

У добре розробленій системі, якби я знайшов операції з кредиторською заборгованістю у таблиці під назвою "aptrx", я би сподівався знайти операції з дебіторською заборгованістю у artrx, транзакції з головної книги у gltrx тощо. Я вважаю, що "apmaster_all" є дещо дивним, але якби я також знайшов "armaster_all", я вважаю, що перший тримав усіх постачальників (на відміну від активних чи неактивних постачальників), а другий аналогічно тримав усіх клієнтів.

В інших проблемних областях ви знайдете інші відомі абревіатури. Звертаючись, ви знайдете абревіатури, такі як "addr" для адреси, "st" для вулиці, "usps" для Поштової служби США, "ups" для United Parcel Service, "cty" для округу, "zip" для вдосконалення зони Код тощо.

Я б не назвав це облуплення. Якщо кредиторські кредитні операції зберігалися в таблиці під назвою "cdrs21", я б назвав це заплутування. (Хоча я колись працював у компанії, яка назвала всі свої модулі монтажу мейнфреймів таким чином. Обмеження символів, а не обфузація.)

Але корисні бази даних зростають, і ви стикаєтеся з проблемою, коли бази даних набувають великих розмірів. Додаючи проблемні домени до своєї бази даних, ви стикаєтесь із ситуаціями, коли стикаються відомі абревіатури. Якщо ви маєте справу зі ЗМІ, то "ap" може також скоротити "Associated Press", "альтернативну пресу" або "попереднє розміщення". Коли це станеться, настав час або відмовитися від скорочень, або перейти до кодів. Чим більша організація (і чим більша база даних), тим частіше я знаходжу коди.

Тільки підкачуючи "мій боже, окуляри, вони нічого не роблять для цієї жахливої ​​конвенції про іменування". Команда управління даними в моєму останньому середовищі заявила, що причиною використання скорочених імен таблиць було обмеження DB2 (у нас був DB2 на z / os та SQL Server) на 18 символів для таблиць і стовпців. Я негайно зазначив, що це було неточним щодо документації з сайту IBM. Потім вони заявили, що це питання COBOL (так, вони активно розроблялися COBOL) у випадку, якщо потрібно поговорити з базою даних, яка потім була спростована жакетами MF. Нарешті, їх відповідь полягала в тому, що це наш стандарт публікації.

Ми звернулися з клопотанням про комітет зі стандартів, щоб збільшити довжину з 18 до 32 символів і отримали обмеження на 30 символів. Це призвело до того, що таблиці переходять від марних імен "SR_M_DLY_ADV_PRD_S" до "IDX_FDSHRCLAS_LIF_RTRN_STATS_X" FML

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

Це звичка (я згоден з Кевінським). Це була реакція на деякі старі (можливо, існують) проблеми на обмеження (довжина імені, пробіл між словами складних імен, багатомовна тощо) операційної системи (наприклад, DOS, Windows) та на деяке програмне забезпечення, яке не обробляло такі імена. Досвідчені люди сказали: "Зробіть так (використовуйте короткі та розділені з підкресленими іменами), і все буде добре".

Мені подобається використовувати описові імена з вищезазначених причин плакатами.

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

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