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

Я работаю над созданием реляционной базы данных, которая отслеживает транзакции, которые происходят на устройстве, над которым я работаю для моей компании. Существуют различные типы транзакций, которые могут происходить на устройстве, поэтому у нас есть поле «trans_type» в одной из наших основных таблиц записей. Моя группа решила сделать тип этого поля целым и рассматривать его как перечислимый тип. Моя интуиция подсказывает мне, что было бы лучше сделать это поле строкой, чтобы данные нашей базы данных были более читабельными и пригодными для использования. Мои коллеги, похоже, обеспокоены тем, что это вызовет больше проблем, чем оно того стоит. Это сравнение строк слишком дорого, а вероятность опечаток - слишком большой барьер.

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

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

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

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

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

Пример:

trans_type
----------
  Я бы
  имя

операции
------------
  Я бы
  TRANS_DATE
  Детали
  trans_type_id (от FK до trans_type.id)

Пример данных:

trans_type

ID | ИМЯ
----------
1 | РАЗМЕСТИТЬ
2 | ОТМЕНА


операции

ID | trans_date | trans_type_id
---------------------------------
1 | 2012-12-31 | 1
2 | 2013-01-09 | 2

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

Это дает дополнительное преимущество обновления строкового значения в одном месте вместо запуска какой-либо процедуры обновления. Вместо 1 = «Красный» он может быть равен «Действительно Красный»

Это не идеально для создания отчетов о производительности по сравнению с просто одной таблицей со строковыми значениями (денормализовано). Индекс в этой области сделает производительность достаточно хорошей.

Большинство СУБД позволит достаточно лошадиных сил. Хотя ваша идея о возможности «чтения» таблицы в ее простой форме данных, присоединение к таблице не представляет особой проблемы. Просто привыкните использовать вид или какой-то подобный объект.

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

Тем не менее, я, безусловно, за то, чтобы не повторять то, что уже было сказано, поэтому просто сошлюсь на принятый ответ (более или менее) на тот же вопрос о переполнении стека: /programming//a/229919 / 114626