Чому прапори / енюми зберігати в базі даних як рядки замість цілих чисел?

Я переглядав скиди SQL деяких відомих CMS, включаючи Drupal 7, Wordpress (якась дуже стара версія) та деякі спеціальні програми на основі Python.

Усі ці дампи містили дані зі строковими прапорами замість цілих. Наприклад, статус на посаду був представлений як published, closedабо inheritзамість 1, 2або 3.

У мене досить обмежений досвід проектування баз даних, і я ніколи не проходив повз простих SQL, але мене завжди вчили, що я повинен використовувати числові / цілі прапори для таких даних. Цілком очевидно , що tinyintспоживає набагато менше місць в базі даних , ніж, наприклад, varchar(9).

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

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

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

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

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

Однак існує багато підходів, схожих на зберігання рядків у базі даних (зокрема MySQL), які є ефективними.

По-перше, у MySQL є enumтип ( docs ), який може бути схожим на булевий або обмежений набір рядків при їх налаштуванні. Він також примушує вводити лише дійсні значення. Це часто набагато корисніше, ніж зберігання 1, 2або 3як значення, оскільки сенс передається з інформацією. Перерахунок накладає штраф, що для додавання або видалення типів потрібна зміна схеми.

Це приводить нас до дочірнього столу та зовнішніх ключів (стосується всіх баз даних). Так, ви зберігаєте яке - то значення в якості ключа (повернення до 1, 2або 3) і значення published, closedі inheritзберігаються в іншій таблиці. Використовуючи вигляд ( документи ), тоді можна зробити так, щоб таблиця містила рядок, а не ключ. Це має перевагу в тому, що для додавання або видалення записів із дочірньої таблиці не потрібно змінювати схему.

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