MS SQL: Где хранить итоги

[StillZero]

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

Т.е. получается есть шапка и содержание.

Соответственно есть итоги по сумме запчастей, сумме ремонта и итого (сумма ремонта+сумма запчастей).

На TOPSPEED я хранил эти итоги в шапке заказа.

Теперь переходим на SQL. Есть ли смысл хранить эти итоги, или считать их каждый раз, когда потребуется?

По объему данных: каждый месяц печатается отчет, содержащий примерно 1000 заказов, в каждом заказе по 3 ремонта и по 3 запчасти в среднем. Т.е. итого получаем 7000 записей.
Будет ли ощутимая разница в скорости при обработке 1000 или 7000 записей?

[ru_alex]

Теперь переходим на SQL. Есть ли смысл хранить эти итоги, или считать их каждый раз, когда потребуется?

По объему данных: каждый месяц печатается отчет, содержащий примерно 1000 заказов, в каждом заказе по 3 ремонта и по 3 запчасти в среднем. Т.е. итого получаем 7000 записей.
Будет ли ощутимая разница в скорости при обработке 1000 или 7000 записей?

Конечно зависит от сервака, но из моего опыта, MSSQL на Celeron2500, 512 Mb разница будет практически не заметна на 1000 или на 7000 записей, а на клиента передается всего одна запись., так что тормозов быть не должно.
И в этом случае не надо заморачиваться по пересчету данных, хотя в MSSQL, наверное, можно и trigger соответствующий навесить, тоже без проблем.

Короче, лучше попробовать и так, и так и сравнить

[Andrew™]

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

Т.е. получается есть шапка и содержание.

Соответственно есть итоги по сумме запчастей, сумме ремонта и итого (сумма ремонта+сумма запчастей).

На TOPSPEED я хранил эти итоги в шапке заказа.

Теперь переходим на SQL. Есть ли смысл хранить эти итоги, или считать их каждый раз, когда потребуется?

По объему данных: каждый месяц печатается отчет, содержащий примерно 1000 заказов, в каждом заказе по 3 ремонта и по 3 запчасти в среднем. Т.е. итого получаем 7000 записей.
Будет ли ощутимая разница в скорости при обработке 1000 или 7000 записей?

храни как в TOPSPEED'е в шапке, а инициализируй через триггера на позиции

[lsgsoftware]

С такими задачами я ковыряюсь уже много лет.Пример-счет фактура,где есть шапка(покупатель, продавец, дата и т.п.) и список товаров,заранее неизвестного объема(счет может идти на сотни и сотни позиций).Так вот уже давно я пересчитываю итоги при добавлении новых позиций.Реализации на DAT,TPS,MYSQL.Объемы таблиц более чем приличные и тормозов нет.А хранить итоги в шапке целесообразно только тогда, когда документ заведомо маленький, делается за один раз и в него не вносят исправлений.Если же документ корректируется(например, ввели не тот товар и затем его удали), то все равно придется делать пересчет после каждой корректировки.

[Andrew™]

С такими задачами я ковыряюсь уже много лет.Пример-счет фактура,где есть шапка(покупатель, продавец, дата и т.п.) и список товаров,заранее неизвестного объема(счет может идти на сотни и сотни позиций).Так вот уже давно я пересчитываю итоги при добавлении новых позиций.Реализации на DAT,TPS,MYSQL.Объемы таблиц более чем приличные и тормозов нет.А хранить итоги в шапке целесообразно только тогда, когда документ заведомо маленький, делается за один раз и в него не вносят исправлений.Если же документ корректируется(например, ввели не тот товар и затем его удали), то все равно придется делать пересчет после каждой корректировки.

ну а какие проблемы, в триггерах даже не пересчёт, а вот такие конструкции

update Шапка SET ИТОГ=ИТОГ-DELETED.SUMMA
update Шапка SET ИТОГ=ИТОГ+INSERTED.SUMMA

замечу - что тут не пересчёт по всем позициям - а изменение итога в шапке применительно по позициям которые реально изменились, добавились, либо удалились

в MSSQL триггер может сработать и на групповую операцию и в inserted и deleted курсорах может быть более одной записи