Правильная организация БД для работы со статистическими данными

Я не являюсь гуру в области баз данных, поэтому не могу могу решить вставшую передо мной проблему без риска, что потом проблем станет еще больше. :)

Итак, начальные условия: PHP5 и MySQL с минимумом возможностей, на выбор MyISAM и InnoDB, но почитав про одно и про другое, от MyISAM я отказался (поправьте, если вдруг я оказался не прав).

Задача: к сожалению, не могу описать задачу конкретно, но я постараюсь максимально изложить суть — формулировка, по-моему, достаточно тривиальна.

Если вкратце, то можно представить, что я собираю статистику про любителей фруктов.
С одной стороны, есть Вася, про которого я знаю следующее: какие фрукты он ест, сколько ест и какие из них он больше всего любит. Любимый фрукт считается исходя из пятибалльной оценки, которую однажды может поставить сам едок, и количеству того, сколько раз этот фрукт был съеден.
С другой стороны, есть Петя и еще сотни человек, про которых я знаю то же самое. На основании имеющейся статистики мне нужно предложить Васе те фрукты, которые он не ел, но которые могли бы ему понравиться.

Рекомендованные для Васи фрукты ищутся следующим образом: мы берем любимые фрукты Васи и ищем тех людей, которые тоже их любят. Затем у этих людей ищем те фрукты, которые любят они и которые Вася не ел, сортируем их по количеству совпадений и выдаем Топ-10.

Таким образом, имеется таблица со строками следующего вида:
[Пользователь] [Фрукт] [Сколько съедено] [Пятибальная оценка]
Из этих записей мне нужно получить те самые фрукты, которые Васе могли бы понравиться.

Цель: в силу ограниченности ресурсов необходимо минимизировать нагрузку на БД, что я планировал сделать за счет правильно организованной работы с базой, то есть:
  1. Правильно организованные структуры таблиц.
  2. Если возможно, найти хитроумный метод, как можно оптимизировать поиск любимого фрукта, так как он предполагает обработку значительного количества данных.


При необходимости можно использовать какие-нибудь дополнительные данные, группировать существующие и прочее — все в разумных пределах, лишь бы на выходе не лег сервер.

PS: все величины, вроде «сотен людей» и «Топ-10», являются исключительно абстрактными и в действительности много больше.
  • Вопрос задан
  • 4022 просмотра
Решения вопроса 1
@rozhik
Рекомендованные для Васи фрукты ищутся следующим образом: мы берем любимые фрукты Васи и ищем тех людей, которые тоже их любят. Затем у этих людей ищем те фрукты, которые любят они и которые Вася не ел, сортируем их по количеству совпадений и выдаем Топ-10.

Совет: Переформулируйте условие. На большом кол-ве товаров в шопах, при вышеприведеном условии частые пустые ответы, а еще чаще получаются хлохмы типа «купившие процессор покупают чернила».
— Рекомендованные фрукты ищутся как наиболее часто-поедаемые фрукты совместно с фруктами, которые ел Вася.
Structure---
kuplenno:
userID,
fruitID

recomendacii
fruitID
fruitID2
cnt
Псевдокод для понимания
function buy( userId, fruitId ) {
    for fruit in SELECT * FROM kuplenno {
        INSERT INTO recomendacii VALUES ( fruitId, fruit, 1 ) ON DUBLICATE KEY
        UPDATE recomendacii where fruitID = fruitID AND fruitID2 = fruit
    }
   INSERT INTO kuplenno VALUES ( userId, fruitId )
}

function getBestFruits( userId ) { 
    return
       SELECT fruitID2, sum( cnt ) as ocenka FROM kuplenno, recomendacii
       WHERE userID = userId AND kuplenno.fruitID = recomendacii.fruitID AND frutID not in (SELECT fruitID FROM kuplenno where userID = userId )
       GRUP BY fruitID2
       ORDER BY ocenka 
       LIMIT 10
}


Вроде как этот способ лучше предсказывает следующую покупку.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 2
mrspd
@mrspd
Вам надо несколько таблиц:

Таблица пользователей
— id
— имя

Таблица фруктов
— id
— название фрукта

Таблица предпочтений пользователей
— id пользователя
— id фрукта
— сколько раз съедено
— оценка

Тут конечно вопрос возникает, как считается оценка по пятибальной шкале, и когда оценивается фрукт, один раз или каждый раз, после съедания?

По сутки такой структуры достаточно будет, чтобы по всякому оперировать данными
Ответ написан
@Amon_Sha
Если «фруктоедов» сотни (а не сотни тысяч), то можно не ломать голову, любая база справится.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы