Как реализовать отношение «Избранное» в базе данных MySQL?

Question

У меня есть приложение, которое отображает списки исполнителей и объектов. Пользователь приложения может выбирать «любимые» как многие из каждого типа, который им нужен. Мне интересно, есть ли стандартный способ реализовать это в базе данных MySQL. Вот мои варианты:

1. Иметь одну таблицу Favorite, хранение UserID, Type, TypeID
   • Type будет либо 'исполнитель' или 'Место'
2. Иметь одну таблицу Favorite, хранение UserID, PerformerID, VenueID
   • Только один из PerformerID или VenueID может иметь значение для каждой записи
3. Есть две таблицы Favorite_Performer и Favorite_Venue, каждый из которых хранит UserID, PerformerID или UserID, VenueID
   • Я думаю, что это будет лучший способ это сделать «реляционные».

Каковы преимущества и недостатки каждого метода, и которые вы могли бы порекомендовать с точки зрения будущего ремонтопригодность? Благодарю.

Answer 1

Вариант 3 является самым чистым. Это делает добавление и удаление любимой самой легкой. И это схема, которую будет реализовывать инфраструктура ORM.

Вариант 1 работоспособен, но вы не можете определить ограничение внешнего ключа для обеспечения целостности. Добавление предикатов WHERE type='Venue' к вашим запросам делает работу с этой таблицей почти такой же, как работа с отдельной таблицей «Favorite_Venue».

Вариант 2 усложняет добавление избранного, если он уже существует. (Это потребует обновления существующей строки, а не вставки. Если у кого-то было два любимых места и пять любимых исполнителей, сколько строк было бы? Но можно было бы определить по крайней мере внешние ключи.

Скажем, у нас было два любимые места и два любимых исполнителей:.

userID venueID performerID 
------ ------- ----------- 
    1  11   177 
    1  NULL   654 
    1  12   NULL 

Когда любимый venueID 11 удаляется, вы бы обновить строку, чтобы установить venueID в NULL Но если venueID 12 удаляется как любимца, вы бы установить столбец в NULL, или удалите строку.Когда вы пошли добавить любимого исполнителя, обновите ли вы существующую строку с номером исполнителя NULL или вставите строку. Неработоспособно, но это сложнее.

Если бы у нас было правило, в котором говорилось, что только один из столбцов locationID или performerID может быть заполнен, то использование предикатов, таких как WHERE venueID IS NOT NULL, сделает работу с этой таблицей почти такой же, как работа с отдельной таблицей Favorite_Venue.

Нижняя линия, я бы выбрал вариант 3, если только не было какой-то веской причины не делать этого.

---

Это не «беспорядок». Каждая из этих таблиц Favorite_Venue и Favorite_Performer имеет цель, «raison d'etre», причина, по которой она есть. Каждая таблица разрешает отношения «многие ко многим».

Объединение этих двух отдельных таблиц «отношения» в одну таблицу фактически создает беспорядок. Если мы добавим столбец, чтобы различать строки (чтобы эффективно отвечать на вопрос, в какой таблице действительно входит эта строка), этот столбец «загромождает». Если мы используем два отдельных столбца в одной строке для двух отношений, это создает беспорядок в коде, который связан с добавлением или удалением избранных.