Лучший способ хранить и обрабатывать информацию об использовании профилирования?

Question

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

Простейшим примером этого может быть отслеживание того, какие продукты пользователь купил и на которые он смотрел, так что, когда кто-то смотрит на продукт, мы можем отобразить «продукты, купленные другими людьми, которые также купили это» ... и т. Д.

Моя неопределенность связана с лучшим подходом к модели данных. Я думаю, что может быть неэффективно писать в таблицу каждый раз, когда кто-то смотрит на продукт, но тогда мне действительно нужно отображать эти данные в той или иной форме для пользователей. Я ищу стратегию, которой легко управлять и которая эффективна снизу вверх. Есть предложения?

EDIT: Под «эффективностью снизу вверх» - я в основном говорю только о принятии решения, которое эффективно как для хранения, так и для извлечения - вероятно, следовало бы просто сказать, что:)

Также, чтобы добавить еще одну сложность, скажем, я хочу отслеживать отношения между продуктами, а не просто регистрировать, что был просмотрен отдельный продукт. Так, например, я мог бы показать на странице продукта A, что люди, которые просматривали продукт A, также просматривали продукт b c и d. В конце некоторых комментариев ниже я думал о создании модели таблицы / django с 2 простыми полями (product_name и last_viewed_date), чтобы я мог выполнить задание, чтобы объединить все представления одного продукта в одну строку (с last_viewed_date принимает дату самой последней записи) ... НО, если я также хочу сохранить историю каждого из этих просмотров, как объяснено выше, как я могу это сделать?

Answer 1

СУБД может обрабатывать гораздо больше записей, чем кажется большинству людей. Если вы не замените существующую реализацию, которая уже обрабатывает огромные объемы трафика, лучше для ясности кодировать сейчас и изменить реализацию позже, если она не может идти в ногу. В идеале, вы должны сделать это каким-то четко спроектированным способом (декоратор функций просмотра, которые вы хотите отслеживать, возможно?), Чтобы позже вы могли поменяться в другой реализации, не затрагивая весь ваш код.

Answer 2

Лучше всего сделать дизайн таблицы базы данных. Таким образом, вы можете порекомендовать похожие товары, которые просматривают люди.

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

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

Ответ отредактирован для комментариев

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

Если вы создадите модель стиля INSERT, а не модель обновления, вы также будете иметь дело с меньшим количеством конфликтов. Вам придется создать механизм архивации, чтобы таблица не увеличивалась в размерах, если вы ограничены в пространстве.

Лично для этого сценария я бы лично использовал СУБД, а не текстовый файл.