Стоит ли преобразовывать перечисления строк базы данных в целые числа?

Question

Существует два способа хранения типов перечислений в базе данных: в виде строки или целого числа.

Сохранение перечисления (sex = {male,female}, account_type = {regular,pro,admin} и т. Д.) В виде строк делает вещи более читабельными, но требует больше места, чем целые числа.

С другой стороны, целые числа требуют отображения перечислений в и из базы данных. В качестве преимущества чувствительность к регистру обрабатывается за пределами базы данных целыми числами.

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

Пример

Возможно, конкретный пример мог бы помочь визуализировать вещи. Давайте возьмем вышеуказанный account_type с базой данных из 100 000 пользователей.

Строковое перечисление

Предполагая 8-битный тип CHAR фиксированной длины

7*100000*8/8 = 700000 bytes

Целочисленное перечисление

Предполагая 8-битные целые числа TINYINT

100000*8/8 = 400000 bytes

Кажется, что размер почти наполовину с целыми числами. Также нужно учитывать индексы.

Answer 1

Ответ, как и следовало ожидать, зависит.

Чем больше база данных, тем значительнее экономия места - не только на диске, но и при вводе-выводе в сети и вычислениях.

Лично я бы хранил целые числа вместо текстовых значений, если только нет прямой поддержки БД для перечислений (как это делает MySQL).

Answer 2

Интервалы занимают меньше памяти, если размер базы данных становится проблемой.

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

Answer 3

На самом деле, что вы, вероятно, хотите сделать, это создать таблицу сопоставления в вашей базе данных, независимо от этого.
Это заботится о нескольких вещах -
1) Вы обычно назначаете столбец Id, а затем присваиваете внешнийключи к соответствующим столбцам.Это предотвращает вставку бессмысленных значений.Это также касается проблем нормализации.
2) С таблицей сопоставления вы можете использовать представления для создания выборок только для базы данных, которые просто меняют значение id для необходимой текстовой строки.
3) С отображениемТаблица, также становится легче иметь дело с проблемами интернационализации (примечание: это не обязательно означает проще , точно).Вот как я мог бы настроить таблицы для этого:

Gender_Mapping
Id | Enum_Mapped_Value | DBA_Readable_Description

Gender_Description
Id | Gender_Mapping_Id | Language_Id | Language_Specific_Description

Для проблем с поиском, (Enum_Mapped_Value) и (Gender_Mapping_Id, Language_Id) должны быть уникальными (или возвращаться уникальными из представления, по крайней мере).
Enum_Mapped_Value должен быть некоторым символьным кодом (может быть, 5 символов?), Который используется для отображения перечисления в базу данных. не используйте либо порядковый номер, либо имя самого перечисления - используйте назначенное конструктором внутреннее значение;В противном случае будущие разработчики могут переупорядочить перечисления или переименовать их, но гораздо вероятнее, что целочисленные значения будут оставлены в покое.
Language_Id следует сопоставить как внешний ключ с некоторой таблицей Language_Mapping, если вы когда-либо план работы с более чем одним языком.

Answer 4

Всегда возникает вопрос о том, будет ли БД рассматриваться людьми, а не через приложения, которые выполняют преобразование. Если человек по какой-либо причине смотрит на БД, текст лучше - особенно в случае, если есть администраторы БД, которые могут не иметь доступа к коду, чтобы увидеть преобразование перечисления.

Если размер хранимых данных более важен, то преобразование в целые числа является лучшей идеей. Но из-за этого улучшенного пространства вы теряете читабельность. Это зависит от того, что является наиболее важным фактором.

Конечно, вы можете включить SProcs или Views или тому подобное, чтобы просмотреть сохраненные целочисленные данные и преобразовать их в строковое значение, что будет иметь смысл, если вам необходимо балансировать между ними.

Но, как сказал Одед, простого ответа не существует. Каждая ситуация будет немного отличаться.