Должен ли я использовать ENUM для первичных и внешних ключей?

Question

Сотрудник создал схему, которая использует столбец ENUM() для первичного ключа в таблице поиска. Таблица превращает код продукта «FB» в его название «Foo Bar».

Этот первичный ключ затем используется в качестве внешнего ключа в другом месте. И на данный момент ФК это тоже ENUM().

Я думаю, что это не очень хорошая идея. Это означает, что для объединения этих двух таблиц у нас будет четыре поиска. Две таблицы плюс две ENUM(). Я прав?

Я бы предпочел, чтобы FK были CHAR(2), чтобы уменьшить количество просмотров. Я также предпочел бы, чтобы PK был также CHAR(2), чтобы полностью уменьшить его.

Преимущество ENUM() s заключается в получении ограничений на значения. Хотелось бы, чтобы было что-то вроде: CHAR(2) ALLOW('FB', 'AB', 'CD'), которое мы могли бы использовать для столбцов PK и FK.

Что такое:

1. Лучшая практика
2. Ваши предпочтения

Эта концепция используется и в других местах. Что если значения ENUM() длиннее? ENUM('Ding, dong, dell', 'Baa baa black sheep'). Теперь ENUM() полезен с космической точки зрения. Должен ли я заботиться об этом, только если есть несколько миллионов строк, использующих значения? В этом случае ENUM() экономит место для хранения.

Answer 1

ENUM следует использовать для определения возможного диапазона значений для данного поля. Это также подразумевает, что у вас может быть несколько строк, которые имеют одинаковое значение для этого поля перистикуля.

Я бы не рекомендовал использовать ENUM для первичного ключа типа внешнего ключа.

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

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

ИМХО, использование ENUM для типа первичного ключа нарушает принцип KISS .

Answer 2

, но когда вы поймали в ловушку только 10 или менее строк, которые не будут проблемой

в * например 1003 * CREATE TABLE `grade`( `grade` ENUM('A','B','C','D','E','F') PRIMARY KEY, `description` VARCHAR(50) NOT NULL ) В этой таблице более чем трудно получить DML

Answer 3

У нас было больше дискуссий об этом, и вот что мы придумали:

Используйте CHAR (2) везде. Для ПК и ФК. Затем используйте ограничения внешнего ключа mysql, чтобы запретить создание FK для строки, которой нет в таблице поиска.

Таким образом, учитывая, что таблица поиска равна L и две ссылающиеся таблицы X и Y, мы можем объединить X в Y без любого поиска ENUM() s или таблица L и могут с уверенностью знать, что в L есть строка, если (когда) она нам нужна.

Мне все еще интересны комментарии и другие мысли.

Answer 4

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