Используйте SUM () или кеширование
У меня нет большого опыта работы с базами данных, поэтому я не знаю, что лучше для долгосрочной работы, лучшей практики и т. д.
Вот мой (гипотетический) случай: представьте, что у вас есть база данных с информацией о клиентах и историей заказов на покупку для каждого. Вы хотите отслеживать, сколько покупает каждый покупатель. Я могу придумать два способа вычислить это:
1) Просто выполняйте SUM () каждый раз, когда это необходимо. Это простое решение, но проблема заключается в том, что этой базе данных может быть 20 лет, и она содержит десятки тысяч строк для каждого клиента. По мере того как в базу данных добавляется больше покупок клиентов, вычисление операции SUM () займет больше времени.
2) Храните сумму в кеше в таблице информации о клиенте, и каждый раз при совершении новой покупки (обновлении, удалении и т. д.) Обновляйте этот кеш. Таким образом, сколько бы ни было заказов на покупку, время расчета не увеличится. Обратной стороной является то, что это менее гибкое решение (только сумма по всем строкам, как насчет суммы за месяц? Другие интервалы? И т. Д.); это кешированное значение могло каким-то образом не синхронизироваться с фактической суммой (технически этого не должно происходить, но это может быть)
Так что же мне для этого делать? Я знаю, что мне не следует хранить что-либо, что я могу вычислить из того, что уже есть в базе данных, но части меня не нравится тот факт, что этот тип вычислений со временем ухудшится, и что есть какая-то элегантность в выборе 2.
Ответы 6
С точки зрения базы данных, в варианте 2 нет элегантности - это будет считаться взломом, который вы могли бы использовать в качестве последнего средства, если ваша база данных станет действительно огромной - вряд ли это произойдет для новичка, настраивающего ее в первый раз ( но возможно).
Было бы много работы по поддержанию итогов; и вы всегда будете иметь дело с вопросом: «Почему детали не составляют общую сумму?»
Выбирайте вариант 1, пока не докажете, что это невозможно. Что в большинстве случаев будет долгим.
Вы можете использовать материализованные представления Oracle или индексированные представления DB2. Они выполняют кэширование точно так, как вы описали, плавно, беззвучно и автоматически.
Ага, когда придет время. БУ сначала бэби-шажки.
Почти всегда 1.
Как часто вы будете запрашивать общую сумму за 20-летнюю историю? Если ответ часто, а производительность оставляет желать лучшего, то можно подумать об оптимизации или OLAP.
Я подозреваю, что вы слишком рано беспокоитесь об оптимизации. Базы данных предназначены для таких целей - пусть позаботятся о кешировании.
В варианте № 2 вы описываете случай преждевременной оптимизации. Использование SUM () всех покупок будет работать очень долго (годы). Когда (если) вы начнете видеть, что эта функция ухудшается, вы можете добавить индексы или итоговую таблицу в свою базу данных, чтобы ускорить процесс. Не усложняйте ситуацию, когда существует простое решение.
Конечно, решение настоящий состоит в том, чтобы попробовать оба решения с 20-летними выдуманными данными и посмотреть, есть ли реальная разница. Я подозреваю, что нет.
Престижность за то, что вы думаете наперед, но напрашивается вопрос: будут ли ваши данные о продажах оставаться в транзакционной базе данных в течение 20 лет?
Наступает момент, когда будет намного проще переместить эти данные в хранилище данных и просто поддерживать текущую базу данных.
Если это новый проект, больше заботьтесь о том, чтобы он работал и чтобы люди использовали его. Пересекая эти мосты, беспокойтесь о масштабируемости.
Используйте вариант 1. Позже, если производительность станет низкой, вы можете определить конкретные узкие места и устранить их с помощью таких опций, как №2, или материализованные представления, или несколько других возможностей.
Я просто добавлю, что еще одна возможность - это создание сводных таблиц. Например, при отслеживании обращений к странице не очень полезно знать, что такой-то IP получил доступ к page1.php в 14:42:04 19.11.2008; но вы можете отслеживать ежедневную статистику для page1.php. В этом случае в конце каждого дня вы можете запускать процедуру для суммирования обращений для каждой страницы и создания записи в сводной таблице, которая, в свою очередь, может быть сильно проиндексирована. Затем ваша отчетность может работать с этой таблицей. Помимо ускорения отчетов, он также может ускорить запись исходных записей, поскольку вам не нужно беспокоиться о блокировке таблиц или построении индексов.
Тем не менее, хорошие индексы могут иметь большое значение для отчетности; и, как предупреждали другие здесь, лучше всего использовать более легкое, даже менее оптимальное решение, пока оно (если вообще когда-либо) не превратится в проблему.
Кстати, «десятки тысяч строк» - это слишком мало для современных движков баз данных, попробуйте сотни миллионов.