#database-design
#database-design
Вопрос:
Итак, я застрял в этом решении о том, как спроектировать свою базу данных для этого отчета о продажах.
Вот сценарий. У меня более 100 тысяч пользователей, каждый из которых проводит 0 или более продаж каждый день. Если у него / нее 0 продаж, то в этот день для этого пользователя ничего не сохраняется, в противном случае, если у него / нее более одной продажи, тогда она просто увеличивается на 1 за этот день.
Теперь вопрос касается проектирования базы данных (с акцентом на конечную производительность). Одним из простых способов сделать это было бы просто создать одну таблицу с датой и идентификатором пользователя и использовать предложение WHERE для получения еженедельных, ежемесячных и годовых показателей продаж данного пользователя.
Table: user_sales_counter
--------------------
user_id, sales, date
Однако проблема, которую я вижу здесь, заключается в том, что если через шесть месяцев я захочу просмотреть отчет пользователя за определенную неделю, мне придется просмотреть 18 миллионов записей в наихудшем сценарии.
Итак, точный вопрос, который я хотел задать, заключается в том, могу ли я создать еще три таблицы для еженедельного, ежемесячного и ежегодного ведения учета, что позволит мне сделать две вещи: я мог бы удалять ежедневные данные о продажах, скажем, старше 2 месяцев, и при этом у меня был бы доступ к еженедельным, ежемесячным отчетам пользователяи т. Д. Запись о продажах, поскольку очистка этих таблиц может быть установлена, например, на 1 год или старше.
Table: weekly_sales_counter
---------------------------
week_no, month_no_year, user_id, sales
Table: monthly_sales_counter
----------------------------
month_no_year, user_id, sales
Table: yearly_sales_counter
---------------------------
year, user_id, sales
Я использую Redis для еще большего минимизации операций чтения в этих таблицах.
Недостаток, который я вижу в этом подходе, заключается в том, что вместо одного мне пришлось бы запускать 4 запроса для регистрации одного счетчика продаж, поскольку счетчик каждой таблицы должен увеличиваться отдельно.
Каков был бы наилучший сценарий для этого? Одна таблица или вторая? Или у вас есть другой подход, который я мог бы использовать?
Спасибо
Комментарии:
1. Единственная таблица кажется мне правильным подходом
2. Спасибо за ответ, но не могли бы вы объяснить, почему? И в чем может быть проблема с подходом с несколькими таблицами?
3. Вы решаете проблему (которой не существует), создавая ненужную избыточность
4. Достаточно справедливо. Но, допустим, он существует, каким тогда должен быть подход?
5. 18 миллионов записей с правильной индексацией и типами данных не должны быть проблемой.
Ответ №1:
По моему опыту, для запроса миллионов данных транзакции потребуется все больше и больше времени. мое предложение:
- создайте одну таблицу, чтобы сохранить наименьшую единицу периода, которую вы хотите использовать в будущем.
- создайте crontab или триггер или что-нибудь для подсчета продаж и группировки по идентификатору пользователя в этой таблице, вы можете посчитать это в конце дня или в конце недели, попробуйте и найдите лучший способ.
- всякий раз, когда вы хотите показать этот счетчик, вы можете просто выбрать из этой таблицы, снова сгруппировав по идентификатору пользователя, это будет легче, чем рассчитывать в таблице транзакций.