Внешний ключ против SET типа данных MySQL
У меня есть база данных MySQL со списком всех моих фильмов, которые я импортировал из базы данных MS Access. Одно поле содержит возможные значения для жанра фильма, фильмы могут иметь более одного жанра, поэтому мне нужен тип данных, который поддерживает эту функцию. В доступе я мог связать одну таблицу «жанр» с полем «жанр» в моей таблице «фильмы», поэтому я мог выбрать ни одну, по одному или несколько жанров на фильм. Когда я переключился на MySQL, я использовал тип данных SET, чтобы определить все возможные значения. Пока все работает отлично.
Я сейчас пытаюсь настроить таблицу в html / php, чтобы показать таблицу mysql. Я хочу, чтобы таблица могла сортировать по: названию, жанру, качеству, рейтингу и т. Д. Но для сортировки по жанру мне потребуются возможные значения из заданного типа данных. Я не знаю, возможно ли получить значения с помощью некоторой команды / кода php, но после того, как я некоторое время бродил по сети, я не видел много приложений, где они используют тип данных SET по очевидным отрицательным причинам. ,
Поэтому я начал изучать возможность использования внешнего ключа. Проблема, с которой я столкнулся, заключается в том, что, насколько мне известно, ключ может содержать только одно возможное значение, которое возвращает меня обратно к началу моей проблемы. Мне нравится идея внешнего ключа, потому что мне было бы проще добавить новый жанр в список.
Есть ли возможность, которую я пропускаю? Можно ли либо получить значения из типа SET в php, либо использовать внешний ключ с несколькими возможностями для одной записи?
Я знаю, что я также могу поместить каждый жанр в свой php-скрипт вручную, но я бы хотел, чтобы все это было в одном месте. Так что, если я добавлю фильм с жанром, который я еще не определил, я могу просто обновить его в одном месте, и все остальное адаптируется к нему.
Решение
Дагон абсолютно прав — у вас проблема со структурой таблиц в вашем бэкэнде. Вы хотите смоделировать отношения многие ко многим, когда на данный момент с вашим текущим бэкэндом лучшее, что вы можете сделать, это отношения один ко многим.
Для просмотра:
У вас есть отдельные фильмы, которые могут иметь много жанров
И у вас есть отдельные жанры, которые связаны со многими фильмами
Реляционные базы данных на самом деле не моделируют отношения «многие ко многим» с одним отношением, они используют рекурсию отношения «один ко многим» и создают два соединения.
Чтобы смоделировать отношения многие ко многим, вам нужны три таблицы
Стол для фильма (который, я думаю, у вас уже есть)
Таблица жанров (которую, я думаю, у вас уже есть)
Соединительная таблица, которая, как предлагает Дагон, будет состоять из двух полей: идентификатор фильма и идентификатор жанра.
Затем вы устанавливаете два отдельных отношения один ко многим. Один от стола фильма к столу соединения и один от стола жанра к столу соединения.
Теперь, если вы хотите узнать все жанры фильма, вы просто фильтруете таблицу соединений по соответствующему идентификатору фильма, а если вы хотите узнать все фильмы с определенным жанром, вы фильтруете таблицу соединений по идентификатору жанра.
Настройте поиск, чтобы соотнести идентификаторы вашего жанра с текстовыми описаниями, и вы можете свободно изменять текстовое описание столько раз, сколько хотите, и замечательно, что если вы все сделали правильно, он обновит каждое значение в ваших формах.
Это абсолютная фундаментальная концепция алгебры множеств, лежащая в основе проектирования SQL и проектирования реляционных баз данных.
Другие решения
Других решений пока нет …