хороший дизайн базы данных: перечислимые значения: целые или строковые значения?

Question

У меня есть столбец в таблице, в котором будет храниться значение перечисления. Например. Большой, Средний, Маленький или дни недели. Это будет соответствовать отображаемому тексту на веб-странице или выбору пользователя из выпадающего списка. Какой дизайн самый лучший?

Сохраните значения как int, а затем, возможно, получите таблицу с соответствующей ей строкой enums / int.

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

В какой точке / количестве значений лучше всего использовать целые числа или строки.

Спасибо.

Answer 1

Предполагая, что выбранная вами СУБД не имеет типа ENUM (который обрабатывает это для вас), я думаю, что лучше использовать идентификаторы вместо строк напрямую, когда значения могут изменяться (либо в значении, либо в количестве.)

Вы можете подумать, что дни недели не изменятся, но что если вашему приложению потребуется добавить поддержку интернационализации?(или злая многонациональная корпорация решает переименовать их после взятия под контроль мира?)

Кроме того, эта большая, средняя и малая категоризация, вероятно, меняется через некоторое время.Большинство значений, которые, по вашему мнению, не могут измениться, могут измениться через некоторое время.

Так что, в основном для предвидения причин изменения, я думаю, что лучше использовать идентификаторы, вам просто нужно изменить таблицу перевода, и все работает безболезненно.Для i18n вы можете просто расширить таблицу перевода и автоматически извлекать нужные записи.

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

Answer 2

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

В качестве примера можно привести саму базу данных Oracle, где они могут позволить себе делать большие заглавные буквы в виде строк в своей системе.столы.Такие вещи, как USER_ALLOCATION_TYPE или подобные, являются нормой.Как вы говорите, строки могут быть более «расширяемыми» и более читаемыми, но в любом случае в коде вы получите:

Static final String USER_ALLOCATION_TYPE = "USER_ALLOCATION_TYPE";

вместо

Static final int USER_ALLOCATION_TYPE = 5;

Поскольку вы либо сделаете это, вы в конечном итоге получите все эти строковые литералы, которые просто жаждут кого-то пойти туда и потерять символ!:)

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

В случае, если вы описываете, что мы делаем, у нас естьтаблица с (PK Int, Description String), а затем мы выполняем просмотры над мастер-таблицами с объединениями, чтобы получить описания, таким образом, мы получаем возможность видеть описания объединенных полей, если должны, и мы поддерживаем производительность.

Кроме того, с отдельной таблицей описания вы можете получить ДОПОЛНИТЕЛЬНУЮ информацию о тех идентификаторах, о которых вы никогда не подумаете.Например, предположим, что пользователь может иметь доступ к некоторым полям в поле со списком, если и только если у него есть такое свойство и так.Вы можете использовать дополнительные поля в таблице описания, чтобы сохранить их вместо специального кода.

Мои два цента.

Answer 3

Мне тоже было бы интересно, чтобы люди думали об этом, я всегда шел путем сохранения enum в справочной таблице, а затем в любых таблицах данных, которые ссылаются на enum, я бы сохранял ID и использовал отношение FK. В определенном смысле мне все еще нравится этот подход, но есть кое-что простое и понятное в том, чтобы поместить строковое значение непосредственно в таблицу.

Если исходить просто из размера, то int равен 4 байта, где в качестве строки используется n btyes (где n - количество символов). Самое короткое значение в вашем поиске составляет 5 символов, самое длинное - 6, поэтому при сохранении действительного значения в конечном итоге потребуется больше места (если это было проблемой).

Если судить по производительности, я не уверен, что индекс int или varchar вернет какую-либо разницу в скорости / оптимизации / размере индекса?

Answer 4

В соответствии с вашим первым примером.Допустим, вы создали таблицу поиска: Размеры.Он имеет следующие столбцы: Id - первичный ключ + идентификатор. Имя - varchar / nvarchar

. В таблице будет три строки: Малая, Средняя и Большая со значениями 1, 2, 3, если вы вставите их вэтот порядок.

Если у вас есть другая таблица, которая использует эти значения, вы можете использовать значение идентификатора в качестве внешнего ключа ... или вы можете создать третий столбец, который является сокращенным значением для трех значений.Он будет иметь значения S, M & L. Вы можете использовать это вместо внешнего ключа.Вам нужно создать уникальное ограничение для столбца.

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

Вы также можете создать значение S / M / L в качестве первичного ключа.

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