Связанные видео Структура таблицы базы данных

Question

Я пытаюсь выяснить, какая структура таблицы будет наиболее подходящей для похожих видео. У меня есть таблица videos, которая содержит информацию обо всех видео. Я планирую добавить новую функцию видео рекомендаций, которую я пока создаю вручную.

Я думал о том, чтобы сохранить ее в столбце таблицы внутри таблицы видео videos.relatedVideos и сохранить данные JSON для соответствующих ID видео. Тем не менее, я хочу, чтобы он был обратно совместимым.

Так, например, если добавить видео с ID = 5 в качестве связанного видео для видео с ID = 10, структура таблицы будет

   | id | videoId | ..... | relatedVideos|

   | 1  | 10      | ..... | [5]          |
   | 2  | 4       | ..... | [3,6,7]      |

Я также хочу видео с ID = 10 действовать как связанное видео для видео с ID = 5. Один из способов сделать это - создать новую запись для #5 в таблице videos, когда я создаю запись для #10

   | id | videoId | ..... | relatedVideos|

   | 1  | 10      | ..... | [5]          |
   | 2  | 4       | ..... | [3,6,7]      |
   | 3  | 5       | ..... | [10]         |

Но я ищу что-то более правильное, где я могу нарисовать отношения «многие ко многим» между видео.

Один из вариантов - создать таблицу relatedVideos и создать новую запись для каждого связанного видео, связанного с основным видео, но это может привести к дублированию записей при добавлении / редактировании связанных видео для любого конкретного видео.

|id | videoID | relatedVideoID|
|1  | 5       | 10            |
|2  | 5       | 15            |
|3  | 5       | 13            |
|4  | 13      | 19            |

Сейчас я делаю следующее: если я просматриваю страницу видео #13 Я выполняю два запроса (Select relatedVideoID from relatedVideos where videoID = 13) и (Select videoID from relatedVideos where relatedVideoID = 13). Я полагаю, что могу сделать то же самое с SQL объединениями или объединениями, мне еще предстоит изучить эти варианты.

Затем я объединяю результаты двух массивов, чтобы получить [19, 5] (я сохраняю только отдельные идентификаторы). Это работа, но я действительно с нетерпением жду возможности найти более правильное решение.

Просто ищу какую-нибудь рекомендацию о том, каким будет хороший подход

Answer 1

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

Вообще говоря, реляционные базы данных плохо справляются с управлением JSON или CSV данные (хотя некоторые из них имеют хорошие функции поставщика). Базовые c SQL запросы быстро становятся намного сложнее, чтобы написать, что они должны, и производительность также страдает ( здесь - это известный пост SO о хранении CSV в столбцах базы данных).

Структура дополнительных данных, которые необходимо хранить, проста и четко определена и соответствует базовому шаблону нормализации базы данных c, поэтому на самом деле нет оснований следовать JSON или CSV paths.

Примечание: для обеспечения целостности данных и избежания дублирования необходимо убедиться, что вы не храните такие пары, как (1, 2), (2, 1). Если вы используете MySQL 8.0, вы можете использовать проверочное ограничение для этого. DDL вашего стола может выглядеть так:

create table related_videos (
    video_id1 int,
    video_id2 int,
    check(video_id1 < video_id2),
    primary key(video_id1, video_id2),
    constraint fk_related_video1 foreign key (video_id1) references video(id),
    constraint fk_related_video2 foreign key (video_id2) references video(id)
);