Стоит ли хранить количество таблиц в другой таблице?

0

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

Я бы только что select Count(*) from Table1 и назвал его днем, но они, кажется, имеют его, когда что-то вставляется в эту таблицу, другая таблица обновляется с самым новым счетом.

Итак, скажем, в Table1 had 100 rows, этот storageTable должен иметь столбец Table1 со счетом 100. Если новая storageTable была вставлена в Table1 то storageTable будет обновлен до 101.

Единственное, что я могу понять, почему это было сделано, было из-за скорости. Если я сделаю select Count(*) from Table1 это займет 4 секунды, чтобы вернуть счет, так как в таблице больше 4 миллионов строк.

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

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

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

  • 0
    Вы можете попробовать свою идею таблицы с триггерами для обновления счетчиков.
Теги:

2 ответа

0

У меня была такая же проблема, когда я работал над одним большим проектом gps. Устройство gps, используемое для отправки координаты каждые 5 секунд, и мне нужно рассчитать общее количество сердечников, накопленный пробег и т.д. Я сделал это в 2 подходах

  1. Сделал отдельную базу данных на основе redis и рассчитал все эти подсчеты и миксы на лету и сохранил ее в redis

  2. Запустите очередь, используя приложение, чтобы сделать запланированное задание, чтобы сохранить эти данные из redis в mysql.

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

0

Это ни хорошая, ни плохая практика. Это просто громоздко.

Очевидно, что сводная таблица очень удобна и оперативна для получения сводных данных. Это удобно.

Однако для хранения сводных данных требуется управление триггерами во всех таблицах - как для insert и для delete. Это громоздко, требуя соответствующей логики в каждой таблице. Это также оказывает (небольшое) влияние на эффективность этих операций. Он также требует ухода при загрузке данных и использовании truncate table.

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

  • 0
    Я думаю, что это также зависит от того, как данные попадают в таблицу и как используется статистика. Для таблицы, используемой для операций OLTP, действительно сложно отслеживать. Для таблицы, которая подается одним заданием ETL, это не так (и я считаю, что это действительно хорошая идея, что процесс ETL может отслеживать свои вставки, удаления и обновления).

Ещё вопросы

Сообщество Overcoder
Наверх
Меню