Я работаю над механизмом рекомендаций к фильмам и столкнулся с проблемой дизайна БД.Моя фактическая база данных выглядит так:
MOVIES [ID,TITLE]
KEYWORDS_TABLE [ID,KEY_ID]
- , где ID - это внешний ключ для MOVIES.id, а KEY_ID - это ключ для таблицы текстовых ключевых слов
Это невся БД, но я показал здесь, что важно для моей проблемы.У меня около 50 000 фильмов и около 1,3 млн. Корреляций ключевых слов, и в основном мой алгоритм состоит в том, чтобы выделить всех, у кого есть одинаковые ключевые слова с данным фильмом, а затем упорядочить их по числу корреляций ключевых слов.
ДляНапример, я посмотрел фильм, похожий на «Отброс», и он вернул «Шесть дней и шесть ночей», потому что в нем было корреляция с наибольшим количеством ключевых слов (4 ключевых слова):
Island
Airplane crash
Stranded
Pilot
Алгоритм основан на большем количестве факторов, но этот - самый важный и самый трудный для подхода.
По сути, сейчас я получаю все фильмы, которые имеют хотя бы одно ключевое слово, похожее на данный фильм, а затем упорядочив их по другим факторам.которые не важны на мгновение.
Не было бы никаких проблем, если бы не было так много записей, во многих случаях запрос длится до 10-20 секунд, а некоторые из них возвращают даже более 5000фильмы.Кто-то уже помог мне здесь (спасибо Марку Байерсу) с оптимизацией запроса, но этого недостаточно, потому что это занимает слишком много времени
SELECT DISTINCT M.title
FROM keywords_table K1
JOIN keywords_table K2
ON K2.key_id = K1.key_id
JOIN movies M
ON K2.id = M.id
WHERE K1.id = 4
Так что я подумал, что было бы лучше, если бы я заранее составил эти списки с рекомендациями фильмовдля каждого фильма, но я не уверен, как оформить столы ... какая бы это была хорошая идея или как бы вы выбрали такой подход?