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

как здорово что все мы здесь сегодня собрались.. (С) митяев (?)
по существу
в приведенных топиках - пасибо, был, читал, даже кое-где писал.
по поводу - Http://talk.mail.ru/forum/talk.ru.house - обязательно посмотрю, спасибо, не знал о таком, хотя и искал нечто подобное.
Теперь о проблеме.
у меня есть система, занимающаяся расчетами с населением за услуги водоотведения. Начисления, перерасчеты, оплата, задолженность и т.д.
в топике
округление сумм я приводил скелетный вид метода начислений, который я применяю
locky
если допустить, что у нас есть перечень услуг с нормами расход услуги на единицу людей и ценой этой услуги, что все лицевые счета всегда пользуются следующими услугами, то алгоритм начислений выглядит вот так:
на выходе получаем подневный расчет каждой услуги на каждый лицевой счет. просуммировав данные в пределах неизменности параметров получаем собственно начисления.
Аналогичным образом считается льгота, только в качестве услуги используется регистрация льгот, а в качестве опорной суммы - проведенные ранее начисления.
Добавляя по вкусу разные дополнительные таблицы связи (не забывая при этом о периоде наличия связи) между ЛС и услугой, ЛС и графиком подачи воды, ЛС и показаниями счетчика - можно изменять начисленную сумму.

Как видим, применен подход «От услуги», который достаточно хорошо описан в топике Система с изменяющимися алгоритмами расчета. .
Подход «От ЛС» дает значительно более худшие результаты по скорости расчета.
К тому же, в моем подходе есть масса дополнительных преимуществ, типа возможности достаточно просто модифицировать алгоритмы расчета, добавлять туда новые условия и т.д.
А теперь о грустном. Как видно из алгоритма, на выходе получается табличка с промежуточными данными. Объем этой таблички порядка (К-во ЛС)*(К-во услуг на одном ЛС)*(К-во дней в месяце), что для 500000 ЛС с холодной и горячей водой составляет около 3*10^7 строк. По сути своей табличка – временная, но из-за организации пофазовой методики начисления создается как постоянная. Ессно, перед расчетом и после него табличку надо чистить. Это- порядочный кусок времени (14% от общего времени расчета).
В топике выполнить truncate table я также привел несколько побочных проблем, а также то, как я считаю нужным их решать.
Но закрадывается в голову сомнение: а правильно ли я думаю? Может, в консерватории что-то надо менять? Т.е. может быть мне нужно менять архитектуру расчетов?

Подневный расчет вызван следующей причиной: любая из характеристик объектов начислений (к-во проживающих, норма, тариф, категория льготы, к-во льготников) может изменится в любой день. к тому же, в любой день человек может быть покдлючен/отключен к индивидуальному/коллективному счетчику (или и к тому и к другому одновременно). На каждый день есть график с указанием, была или не была горячая/холодная вода.
Далее, как видно из примера расчет провизводится для нескольких счетов одновременно, а в этом случае минимальный период неизменности всех параметров - 1 день.

Самое главное - не задавай в форуму вопрос, а нельзя ли отключить логгирование.
Популярно объяснять, что с точки зрения теории - это не есть правильно, а значит не есть правильно и с точки зрения практики. А сам ты... в общем, учите матчасть и читайте BOL, маладой человек! :-))
когда то подымался мною вопрос "о ненужных возможностях", мы там чуток покусались.
Причем с точки зрения Sybase, если не ошибаюсь, выключение логгирования - полезная весчь, с точки зрения Informix - тоже (только там есть нескоко ограничений, которые практически на нет сводят преимущества).
Вооот...
дык а подход то возникает из постановки задачи - учет параметров объекта начисления с точностью до 1-го дня.
Не так, чтобы - льгота - на весь месяц, проживающие - тоже, а так чтобы "С-по"...

>Зачем же эту таблицу постоянно чистить перед расчетом?
Уж больно велик получается размер кэш-таблицы - для 7 лет около 672Gb.

Боюсь, что подход с кэшированием, предложенный ASCRUS подходит для задач во первых, с относительно небольшим объемом кэшированных данных, во вторых для задач, в которых в течении текущей работы конечный результат формируется более чем на 70%.
К примеру в той же зарплате каждый табельный номер практически гарантированно будет обработан в отчетном месяце.
В моем случае изменения происходят по 2-5% ЛС в месяц - их я могу положить в кэш. но по всем остальным надо будет затем определить - есть они в кэше или нет, и если их там нет - посчитать. вот это момент "определить есть или нет" - достаточно тяжел. в 95% выгоднее просто посчитать.
Кста, а вообще кто-нибудь еще применяет подобных подход - расчет не ЛС счета по всем услугам а расчет услуги по всем ЛС?

кстати, только-только обратил внимание: и в моем варианте с "временным" кэшем, и в варианте ASCRUS с "постоянным" кэшем есть одна и та же операция: очистка части кэша :-( Вот её-то и хочеться избежать.
Наверное, для меня наилучшим выходом всё-же будет разведение расчетов по разным промежуточным таблицам с truncate'ом их в конце расчета. это ко всему прочему повысить конкурентность системы.

>Т.е. у вас проблема только в том, что долго удаляются строки из таблицы? Эта операция занимает основную часть времени при расчете?
Ну, не основную часть времени, а, как я уже писал, 14% от времени расчетов.
просто столкнулся с тем что достаточно сложно соптимизировать
при наличии подходящих индексов :-)
Вот и закралось в голову сомнение: может проблема не в этом, а в подходе к расчетам в целом? Может, не следствие надо лечить, а причину? И если причину, то как её лечить?