Это правильное использование типа данных перечисления MySQL?

Question

Я недавно начал заниматься фрилансом на PHP + MySQL в свободное время, чтобы увеличить свой доход от работы на полную ставку, где я пишу код на C # / SQL Server.Одно из существенных различий, связанных с базами данных, которое я заметил, заключается в том, что MySQL имеет тип данных enum, а SQL Server - нет.

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

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

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

Никогда ранее не сталкивался с типом данных ENUM в базе данных, мне интересно,разумно использовать эту функцию, или если есть проблемы, которые я не предвидел, которые могли бы вернуться, чтобы укусить меня в результате этой архитектуры данных.Опытные MySQL'ы, что вы думаете?

Answer 1

Короче говоря, это не очень хороший дизайн.Внешние ключи имеют назначение.

С документация для типа ENUM :

Перечисление может содержать максимум 65 535 элементов.

Ваш дизайн не позволит вам хранить более 65 тыс. Разных имен исполнителей.

Рассматривали ли вы, что происходит, когда вы добавляете имя нового исполнителя?Я полагаю, вы используете ALTER TABLE для добавления новых типов перечислений?Согласно аналогичный вопрос SO, это очень дорогая операция .Сравните это со стоимостью простого добавления еще одной строки в таблицу artist.

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

Есть и много других проблем с этим подходом.Я думаю, что упрощение такой структуры базы данных делает вас плохой услугой (внешние ключи или наличие нескольких таблиц - это не плохо!).

Answer 2

Я буду честен - я остановился, когда прочитал ...

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

Если я правильно понимаю, это означает, что существует перечень всех художников. Но это перечисление художников определенно будет точкой вариации: будет больше художников. Я искренне сомневаюсь, что лейбл никогда не планирует увеличивать или изменять список артистов;)

Таким образом, на мой взгляд, это неправильное использование перечисления.

Я также не думаю, что целесообразно выполнять ALTER TABLE для того, что неизбежно является довольно обыденным вариантом использования. (Создать / прочитать / обновить / уничтожить исполнителя) У меня нет номеров, подтверждающих это мнение.

Вы должны рассматривать это как вопрос о том, какая информация является сущностью или атрибутом сущности: для лейбла записи исполнители являются сущностями, а типы носителей могут не быть. Художники имеют много информации, связанной с ними (имя, жанр, награды, URL веб-сайта, старшинство ...), что говорит о том, что они являются сущностью, а не атрибутом другой сущности, такой как Release. Кроме того, художники создаются / читаются / обновляются и уничтожаются как часть обычного повседневного использования системы, что еще больше указывает на то, что они являются сущностями.

Сущности, как правило, получают свои собственные таблицы. Теперь, когда вы смотрите на Media Type этих выпусков, вы должны спросить себя, есть ли у Media Type какая-либо другая информация ... если у вас есть что-то большее, чем Name, у вас есть новая сущность. Например, если ваша система должна отслеживать, является ли тип медиа устаревшим, теперь есть 2 атрибута для типа медиа (имя устарело), ​​и это должен быть отдельный объект. Если Типы Medai имеют только Имя в рамках того, что вы строите, то это атрибут другого объекта и должен быть только столбцом, а не таблицей. На этом этапе я хотел бы рассмотреть использование перечисления.

Answer 3

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

1. Когда вам нужно добавить дополнительные параметры в enum colum. Если ваша таблица содержит много данных, потребуется перестроить таблицу, добавив дополнительную опцию
2. Когда вам нужно перенести базу данных на другую технологию (enum доступен не во всех продуктах баз данных, например, MSSQL)