Когда денормализовать проект базы данных

Я знаю, что нормализация (z) действия широко обсуждалась в Stack Overflow. Я читал многие из предыдущих обсуждений. Однако у меня есть несколько дополнительных вопросов.

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

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

1) С временными данными. Например, создается счет-фактура, который ссылается на продукт. Если через год покупатель запросит копию этого счета, мы должны иметь возможность предоставить точную копию оригинала. Что делать, если цена, название или описание продукта были обновлены? Старший парень предложил скопировать цену и другую информацию о продукте в таблицу счетов. Я думаю, может быть, нам стоит создать другую таблицу, такую ​​как productPrice, с полем даты, чтобы мы могли отслеживать изменения цены с течением времени. Думаю, нам понадобится то же самое для описания и названия продукта? Кажется сложным. Как вы думаете?

2) База данных - это система учета. Я не очень хорошо разбираюсь в бухгалтерском учете. На данный момент некоторые сводные данные получены и сохранены в базе данных. Например, общий объем продаж за год. Мой старший научный сотрудник сказал, что бухгалтеры любят проверять, все ли правильно, сравнивая это значение с данными, которые фактически рассчитываются из счетов-фактур и т. Д., Чтобы дать им уверенность в том, что приложение работает правильно. Он сказал, что на данный момент, например, мы можем определить, удалил ли кто-то счет за прошлый год по ошибке, потому что итоговые суммы не будут такими же. Он также отметил, что вычисление этих итогов на лету может быть довольно медленным. Конечно, я сказал, что данные не должны дублироваться и всегда должны вычисляться при необходимости. Я предложил использовать SQL Reporting Services или какое-либо другое решение, которое будет генерировать эти отчеты в одночасье и кэшировать их. Во всяком случае, он не уверен. Есть комментарии по этому поводу?

Большое спасибо :)
Он также указал, что вычисление этих итогов на лету может быть довольно медленным. Конечно, я сказал, что данные не должны дублироваться и всегда должны вычисляться при необходимости. Я предложил использовать SQL Reporting Services или какое-либо другое решение, которое будет генерировать эти отчеты в одночасье и кэшировать их. Во всяком случае, он не уверен. Есть комментарии по этому поводу?

Большое спасибо :)
Он также отметил, что вычисление этих итогов на лету может быть довольно медленным. Конечно, я сказал, что данные не должны дублироваться и всегда должны вычисляться при необходимости. Я предложил использовать SQL Reporting Services или какое-либо другое решение, которое будет генерировать эти отчеты в одночасье и кэшировать их. Во всяком случае, он не уверен. Есть комментарии по этому поводу?

Большое спасибо :)
Ура
Марк

ИЗМЕНИТЬ

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