Это правильное использование типа данных перечисления MySQL?
Недавно я начал заниматься фрилансом на PHP + MySQL в свободное время, чтобы увеличить свой доход от работы на полную ставку, где я пишу код на C#/SQL Server. Одно из существенных различий, связанных с базами данных, которое я заметил, заключается в том, что MySQL имеет тип данных enum, а SQL Server - нет.
Когда я заметил тип данных enum, я сразу решил сгладить свою модель данных в пользу того, чтобы иметь большую таблицу, в которой используются перечисления, а не множество таблиц меньшего размера для дискретных объектов и одну большую таблицу типа "мост".
Сайт, над которым я сейчас работаю, предназначен для лейбла. У меня есть только одна таблица для хранения релизов для метки, таблица "релизы". Я использовал перечисления везде, где я обычно использовал внешний ключ для отдельной таблицы - имя исполнителя, имя метки и некоторые другие. Пользователь имеет возможность редактировать эти столбцы перечисления через бэкэнд. Основным преимуществом перечислений, которые я вижу по сравнению с использованием текстового поля для этого, является то, что имена исполнителей будут использоваться повторно, что должно улучшить целостность данных. Я также вижу преимущество в том, что в базе данных меньше таблиц.
Кстати, у меня все еще есть одна дополнительная таблица и таблица мостов - есть функция "Теги" для добавления тегов к определенному выпуску, и, поскольку это отношение "многие ко многим", я чувствую таблицу дискретных тегов и Мостовая таблица для присоединения тегов к релизам подходит
Никогда ранее не сталкиваясь с типом данных ENUM в базе данных, я задаюсь вопросом, разумно ли я использую эту функцию или есть проблемы, которые я не предвидел, которые могли бы вернуться из-за этой архитектуры данных. Опытные MySQL'ы, что вы думаете?
3 ответа
Я буду честен - я остановился, когда прочитал...
Я использовал перечисления везде, где я обычно использовал внешний ключ для отдельной таблицы - имя исполнителя, имя метки и некоторые другие.
Если я правильно понимаю, это означает, что существует перечень всех художников. Но это перечисление художников определенно будет точкой вариации: будет больше художников. Я искренне сомневаюсь, что лейбл никогда не планирует увеличивать или изменять список артистов;)
Таким образом, на мой взгляд, это неправильное использование перечисления.
Я также не думаю, что целесообразно выполнять ALTER TABLE для того, что неизбежно является довольно обыденным случаем использования. (Создать / прочитать / обновить / уничтожить исполнителя) У меня нет цифр, подтверждающих это мнение.
Вы должны рассматривать это как вопрос о том, какая информация является сущностью или атрибутом сущности: для звукозаписывающего лейбла артисты - это сущности, а типы носителей - нет. Артисты имеют много информации, связанной с ними (имя, жанр, награды, URL веб-сайта, старшинство...), что говорит о том, что они являются сущностью, а не атрибутом другой сущности, такой как Release. Кроме того, художники создаются / читаются / обновляются и уничтожаются как часть обычного повседневного использования системы, что еще больше указывает на то, что они являются сущностями.
Сущности стремятся получить свой собственный стол. Теперь, когда вы смотрите на Media Type этих выпусков, вы должны спросить себя, есть ли у Media Type какая-либо другая информация... если у вас есть что-то большее, чем Name, у вас есть новая сущность. Например, если ваша система должна отслеживать, является ли тип медиа устаревшим, теперь есть 2 атрибута для типа медиа (имя устарело), и это должен быть отдельный объект. Если Типы Medai имеют только Имя в рамках того, что вы строите, то это атрибут другого объекта и должен быть только столбцом, а не таблицей. На этом этапе я хотел бы рассмотреть использование перечисления.
Короче говоря, это не очень хороший дизайн. У внешних ключей есть цель.
Перечисление может иметь максимум 65 535 элементов.
Ваш дизайн не позволит вам хранить более 65 тысяч разных имен художников.
Рассматривали ли вы, что происходит, когда вы добавляете имя нового исполнителя? Я полагаю, вы управляете ALTER TABLE добавить новые типы перечислений? Согласно аналогичному вопросу SO, это очень дорогая операция. Сравните это со стоимостью простого добавления еще одной строки в artist Таблица.
Что произойдет, если у вас есть более одной таблицы, которая должна ссылаться на имя исполнителя / исполнителя? Как вы повторно используете значения перечисления в таблицах?
Есть и много других проблем с этим подходом. Я думаю, что упрощение дизайна вашей базы данных, как это делает вас реальной плохой услугой (внешние ключи или наличие нескольких таблиц не плохая вещь!).
Я не думаю, что вы можете использовать перечисления в таких областях, как художники. Как будто вы ограничиваете рост своего приложения. Поддерживать колонку будет очень сложно. Использование ENUM не является проблемой само по себе. Но будет проблема в следующих ситуациях
- Когда вам нужно добавить дополнительные параметры в enum colum. Если ваша таблица содержит много данных, потребуется перестроить таблицу при добавлении дополнительной опции.
- Когда вам нужно перенести базу данных на другую технологию (enum доступен не во всех продуктах базы данных, например, MSSQL)