MySQL: сложные запросы или поля отслеживания / счетчика

Question

Я просто думаю о разработке базы данных MySQL, и часто бывают ситуации, когда

• Конкретное действие выполняется или не выполняется, и, следовательно, данные хранятся или не хранятся в базе данных
• Независимо от того, предпринял ли пользователь конкретное действие, статистически отображается

Примером этого может быть:

Пользователь заполняет или не заполняет опрос. Если они заполняют опрос, данные, которые они предоставляют, хранятся в базе данных. Отображается общее количество пользователей, заполнивших опрос.

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

• создать поле типа BOOL, для которого задано значение TRUE после завершения исследования; Затем мы рассчитываем количество пользователей, которые завершили опрос, используя простой COUNT(*) WHERE field=TRUE
• рассчитать количество пользователей, заполнивших опрос, используя предоставленные ими данные, присоединившись к таблицам пользователей и результатов опроса и сгруппировавшись по пользователю

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

Каков будет ваш подход к решению этой проблемы? Для небольших приложений я обычно просто пишу сложные запросы и кеширую их результаты (иногда используя views , чтобы сделать вещи более управляемый). Но в более крупных приложениях с потенциально большим количеством объединений у меня может возникнуть желание пометить пользователей полем действия, чтобы чтение было проще и дешевле.

Answer 1

Лучшим решением является индексированное представление (терминология SQL Server) или материализованное представление (терминология Oracle) или материализованная таблица запросов (терминология DB2). Все эти решения поддерживают актуальность данных в режиме реального времени. Без обслуживания.

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

• триггеры
• заданий cron

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

Помогает, что в реальном мире большинство таких требований действительно не должны быть актуальными в реальном времени. Такие цифры обычно поддерживают управленческие решения; задержка даже дня часто приемлема. (Другими словами, иногда это помогает воспринимать это как проблему хранилища данных или как отчет, а не как проблему OLTP.) Мне приходилось обсуждать подобные требования много раз. У меня никогда не было никого, кто бы отказывался принять двухчасовой цикл обновления. (Но это, безусловно, зависит от приложения.)

Answer 2

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

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

Answer 3

То, что вы описываете, называется «денормализованным представлением», то есть таблицей, которая содержит результаты, которые можно вычислить из других данных, уже имеющихся в базе данных. Причиной для этого действительно является производительность, независимо от того, делать это или нет, зависит от стоимости (повторного) генерирования данных, усилий в вашем коде, необходимых для обеспечения их согласованности, и дополнительного объема пространства базы данных для хранения вычисленных значений. значения.