Зачем хранить флаги / перечисления в базе данных как строки, а не как целые числа?

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

Все эти дампы содержали данные со строковыми флагами вместо целочисленных. Например, статус на должность был представлен как published, closedили inheritвместо 1, 2или 3.

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

Так чего мне не хватает? Разве это не пустая трата данных и избыточность данных? Разве просмотр, поиск и индексирование не были бы немного быстрее, если бы в этих столбцах использовались целые числа вместо строк?

Да, хранение строк вместо чисел может занять больше места. Причина, по которой высококлассные платформы в любом случае делают это, заключается в том, что они считают, что преимущества этого решения превышают его стоимость.

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

Как насчет стоимости? Емкость хранения данных давно не была узким местом в CMS, поскольку диски стали такими большими и такими дешевыми. Время программиста, с другой стороны, обычно становится дороже - поэтому все, что тратит усилия на разработку на дисковое пространство, также полезно с точки зрения бизнеса.

Да, хранение таких вещей, как yesили trueзаймет больше места, чем крошечный. Это не должно удивлять. Это также делает индексацию и, следовательно, объединения менее эффективной для базы данных. Это также имеет штраф за возможную путаницу за то, что является правильным значением ( yesпротив y).

Однако есть много подходов, которые выглядят как хранение строк в базе данных (в частности, MySQL), которые эффективны.

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

Это приводит нас к дочерней таблице и внешним ключам (применимо ко всем базам данных). Да, вы сохраняете какое - то значение в качестве ключа (возврат к 1, 2или 3) и значение published, closedи inheritхранятся в другой таблице. Используя представление ( docs ), можно сделать так, чтобы таблица выглядела так, как будто таблица содержит строку, а не ключ. Преимущество этого заключается в том, что для добавления или удаления записей из дочерней таблицы не требуется никаких изменений схемы.

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