Ну, у меня небольшой веб-сайт, посвященный видео, и на самой странице видео есть полоса «похожих видео», похожих на большинство сторон видео (например, на YouTube), и в настоящее время все, что я делаю, это выбираю один из его тегов случайным образом и нахожу другие видео с таким же тегом. Неудивительно, что это не очень хороший метод, поскольку некоторые теги очень расплывчаты, а некоторые видео имеют неправильные теги.
Пример текущего запроса:
SELECT video_name FROM videos INNER JOIN videotags ON videos.id=videotags.video_id INNER JOIN tags ON tags.id=videotags.tag_id WHERE tag_name='x' AND videos.id<>'y' LIMIT 5
Где x - любой из тегов текущего видео, а y - идентификатор текущего видео. (П.С. Я использую параметризованные запросы, не волнуйтесь)
Мне просто любопытно, как вы все справитесь с этим, может быть, было бы лучше включить похожие названия видео?
Вот как настраиваются мои таблицы базы данных:
VIDEOS TABLE
------------
video_id [PK,auto_increment] int(11)
video_name varchar(255)
TAGS TABLE
----------
tag_id [PK,auto_increment] int(11)
tag_name varchar(255)
VIDEOTAGS TABLE
---------------
tag_id [PK,FK] int(11)
video_id [PK,FK] int(11)
Очевидно, что в таблице видео больше столбцов, но это просто иллюстрирует простое отношение «многие ко многим» с автоматически увеличивающимися первичными ключами с обеих сторон
Сайт построен на PHP с базой данных MySQL, но это действительно не имеет значения:)
РЕДАКТИРОВАТЬ: Ходили разговоры о том, чтобы пойти по органическому маршруту, поэтому я решил опубликовать две другие таблицы, которые связаны друг с другом и связаны с просмотром видео и оценками видео. Теперь обратите внимание, что я не собираюсь добавлять дополнительные столбцы специально к таблице просмотров видео из-за проблем с конфиденциальностью (да, я знаю, что храню IP-адреса в таблице рейтинга)
VIDEOVIEWS TABLE
----------------
video_id [FK] int(11)
view_time datetime
VIDEORATINGS TABLE
------------------
video_id [PK,FK] int(11)
ip_address [PK] varchar(15)
rating int(1)
rate_time datetime