Структура базы данных MySQL для временной диаграммы и генерации отчетов - PullRequest
Новая
       27

Структура базы данных MySQL для временной диаграммы и генерации отчетов

0 голосов
/ 20 октября 2018

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

Я должен показать, сколько пользователей понравилось или не понравилось продуктом в определенный промежуток времени, через график и сгенерировать отчет.Таким образом, мое приложение должно создавать дневной график за август 2018 или месячный график за 2018 год по конкретному продукту.График должен показывать, сколько пользователей понравилось или не понравилось продукту ежедневно, если это график дня. Аналогично, это может быть недельный, месячный или годовой период времени

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

products: id, name, descp...etc // products table

users: id, name, email ...etc // users table

user_reactions: id, user_id(foreign key), product_id(foreign key), action(liked or disliked, tinyint), feedback // user_reactions table

data: id, product_id(foreign key), date(Y-m-d), total_like, total_dislike. // data table, will be used to make graph and report

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

Примечание: Мое приложение будет в PHP и MySQL

1 Ответ

0 голосов
/ 20 октября 2018

Ну, нет правильного ответа на ваш вопрос.Потому что ответ на ваш вопрос называется ответом, основанным на мнении.Мы с тобой наверняка получим достаточно голосов.Но все же выслушай меня, мой друг, потому что я был в твоем состоянии однажды.

Есть цитата известного профессора мистера Дональда Кнута

Преждевременная оптимизация - корень всего зла

Мы должны забыть о малой эффективности, скажем, в 97% случаев: преждевременная оптимизация - корень всего зла.Однако мы не должны упускать наши возможности в этих критических 3%.

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

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

Создайте систему с вашими знаниями и пониманием.Потому что нет единого прямого пути к проблеме. создать функцию -> вы столкнулись с проблемой -> настроить свое приложение -> и промыть и повторить. Однажды ваш собственный опыт покажет вам правильный путь.

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

Надеюсь, я ответил на твой вопрос.

...