У меня есть таблица с полем с именем Schedule с типом данных varchar (20), которая в настоящее время содержит разделенный запятыми список из шести (6) двух (2) кодов расписания. Коды тезисов варьируются от [a1-a9] - [g1-g9]. Теперь я понимаю, что это плохая практика, поскольку она ограничивает производительность запросов и в значительной степени опирается на программный код для обеспечения непрерывности данных. В настоящее время я не выполняю никаких запросов к этим данным, но я вижу, где это может быть полезно.
Каков наилучший вариант для замены этого столбца? Моей первой мыслью было создание справочной таблицы с ограничением внешнего ключа, связывающим ее с предметом расписания, и каждый код в виде столбца с типом данных tinyint / bool. Однако это будет таблица с более чем 60 столбцами, которая звучит так, как будто я вступаю в другой анти-шаблон.
Есть ли лучшее решение, чем справочная таблица? Есть ли лучший способ реализовать такую таблицу? У меня есть полный контроль над базой данных, и я могу реализовать любое решение, обеспечивающее наилучшую производительность.
Редактировать:
Под «справочной таблицей» я имел в виду, что @ gordon-linoff описано ниже. Таблица с более чем 60 статическими записями, на которые затем будет ссылаться ограничение внешнего ключа третьей таблицей, связывающей расписания с их субъектами.
Я думаю, что это дублирующий вопрос , как и предполагалось,выбранный ответ - это широкий комментарий по нормализации данных без какого-либо конкретного предложения о наилучшей практике, а остальные ответы - это варианты «Да, это плохая практика».
Я очень мало знаю об управлении базами данных. Если статическая таблица и соединительная таблица являются лучшей практикой, тогда у меня есть ответ. Меня просто беспокоит статическая таблица, которая, вероятно, никогда не изменится.