Когда хранить предварительно рассчитанные значения, а когда их вычислять при извлечении?

По поводу ваших двух вопросов:

Я могу сказать новым разработчикам, что эти структуры не нормализованы, но они могут сказать, что это быстрее. Как мне противостоять этому? Могу ли я противостоять этому? Другие так структурируют свои базы данных ?!

Это может быть быстрее, но это не обязательно так: всякий раз, когда вы решаете добавить дополнительную информацию в таблицу (дополнительные поля, в вашем случае), вы также добавляете штраф за производительность, потому что таблица становится больше, что может означать, что из сервер для клиентов, или для подкачки в или из памяти ... также, если поле предназначено для ускорения запросов, оно, вероятно, будет иметь один или несколько индексов для этого, что снова снижает производительность во время обновлений и вставок. Однако главный момент - это тот, на который я намекнул в своем комментарии: «кэшированные» и «предварительно вычисленные» значения делают систему более хрупкой с точки зрения целостности данных. Вы уверены, что event_creator_id всегда правильно указывает на настоящего создателя, даже если кто-то изменил исходное значение? Если да, то это тоже связано с затратами как с точки зрения вычислений (вам нужно обновить все таблицы при смене создателя), так и с точки зрения фактических усилий по разработке и тестированию (вы уверены, что никто не забыл распространить изменения в предварительно вычисленные поля? ).

То же самое касается агрегированных значений, таких как «цена со скидкой» или промежуточные итоги ... и изменение исходных данных, вероятно, происходит гораздо чаще, чем изменение информации «создателя события». Опять же, существует ли надлежащий механизм «аннулирования кеша», чтобы гарантировать, что общие продажи пересчитываются всякий раз, когда кто-то завершает продажу? Что насчет возвращенного товара? Кто-нибудь рассматривал стоимость обеспечения целостности?

Текущие итоги и другие производные значения должны быть реализованы с использованием представлений, чтобы кэширование, если оно есть, выполнялось реальной машиной СУБД, которая знает, как правильно с этим позаботиться.

Есть ли эмпирическое правило или набор принципов, которые я могу использовать, чтобы сказать, что - «о, это будет медленнее, но только на 1%, так что это нормально» и т. Д.?

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

Другими словами: создание таблицы с избыточной кэшированной информацией - еще один пример преждевременной оптимизации, которого следует избегать любой ценой.

См. Также это - особенно ответы

Любая книга по базам данных, которую я читал по реляционному дизайну, всегда включала раздел о «запланированной» избыточности или «ограниченной» денормализации. Это зависит от окружающей среды. Wells Fargo предварительно рассчитывает итоги выписки по счету и сохраняет предварительные расчеты.

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

Планируемое резервирование - это нормально!