Vowkmayton и не умеют и не хотят оптимизировать тяжёлые отчёты типа "Переноса остатков".
Перенос остатков - это один из центральных моментов в работе бухгалтерских программ. Есть несколько подходов решения этой проблемы, у каждой свои плюсы и минусы.
В моих программах остатки никуда не переносятся (по принципу - данные должны находиться на месте и никуда не переноситься - тогда и сохраняться будут лучше). Соответственно, не нужен отчет по переносу остатков - наиболее сложный и уязвимый момент работы системы. Лет пять уже нихто не занимается созданием бэкапов - и работает всё нормально. Мой подход - пусть машина повычисляет подольше, но чтобы данные никуда не двигать.
1С-ники решили этот так: в регистрах хранят значения лишь для некоторого определенного момента времени (который они обозвали точкой актуальности), а для остальных моментов времени система вынуждена каждый раз вычислять: если надо вперед посчитать - прибавляют приход и вычитают расход, если назад - то наоборот поступают.
Еще один подход - переход на следующий месяц. Преимущество - простота и ясность, алгоритм как бы сам напрашивается. Недостаток - невозможность выполнять отчеты в прошлых месяцах (конечно, если не делать архивы за прошлые месяцы, но этот подход я считаю примитивным).
Возможно, существуют иные способы решения этой проблемы, и именно от этого зависит дальнейшее построение всей системы.

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

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

Идеальная система с моей точки зрения и думаю(надеюсь) Вашей и mayton , будет та система которая не меняя сути хранения данных позволит изменить точку наблюдения и систему координат для восприятия данных, под людей не учивших физику в школе и вузе.

Что касается аэродинамической трубы , то там все просто как ясный день,

Метод конечных элементов и метод гауса
С формулами и матрицами работать проще чем с людьми наделенными властью и тараканами в их голове .

mikhail_nавторЧто касается аэродинамической трубы , то там все просто как ясный день,

Метод конечных элементов и метод гауса

И какое же по вашему мнению метод конечного элемента и метод решения СЛАУ по Гауссу имеют отношение к автоматизации аэродинамической трубы? Вы вообще то сколько автоматизированных труб видели реально в жизни а не по телевизору?

Метод конечных элементов, это не конкретный метод ( алгоритм) это концепция( определенная абстракция как ООП) для решения задач которые описываются системой линейных и диф уравнений.

Лично я трубу не создавал, последний семестр высшей математики в Универе ему был полностью посвящен(1993 -94 годах это было приблизительно).

За одну пару исписав полностью тетрадку в 12 листов формулами и матрицами мы решали такие задачи например:

Есть стержень из материала помещенный в среду , к стержню с одного торца прикладывается
температурное воздействие, определить температуру в любой точке пространства ( в стержне или в разумной близости от него).

Или в однородной среде с определенной плотностью и давлением летит шар с определенной скоростью, определить давление в любой точке среды в разумной близости от поверхности шара.

Это как раз задача о моделировании трубы.

Это самые простые задачи для студентов, которые должны решаться за одну пару в соответствии с учебным планом ( специальность у меня не математическая).

Со слов препода все(любые) задачи, решение которых можно привести к системе диф. уравнений решаются с помощью метода конечных элементов.

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

Минутку. Насчёт постановщиков и аналитиков - понятно.

Но экономисты и бухгалтера не решают как реализовать архитектуру комплекса учёта. Решает, очевидно разработчик.

Или я не понял.

Согласен , экономисты и бухгалтера являются заложниками,
но только в том случае если они не участвуют ( не утверждают ) ТЗ.
Если участвуют и утверждают а тем более настаивают , то ответственность за кривую архитектуру на них тоже в какой то мере ложится.

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

1) Это чисто математический подход, а с точки зрения надежности хранения данных разница большая, а точнее принципиальная. Информатика - все-таки не математика, котя (к несчастью) уроки инофрматики в 90% случаев в школе проводят учителя-математики.


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

XDiaBLo
Не знаю о чём вы, а у нас в системе, когда нужно посчитать остаток на конкретную дату, я беру текущий остаток, и из него вычитаю все финансовые транзакции, до заданного момента.

А я делаю что то типа

Заранее удостоверившись, что были движения в периоде time between ......

XDiaBLoonstat-,

А на словах? Своё кстати тоже недостаточно точно объяснил. Я в банке работаю. По пластиковым картам. В общем есть счета, и текущие остатки на них, и есть таблица транзакций, и думаю вы можете себе представить, при нескольких сотнях тысяч клиентов, сколько будет транзакций, если учесть, что у каждого по несколько счетов, и с каждого счёта, хотя бы раз 10 в месяц снимают деньги.
Беру текущий остаток, и вплоть до конкретной даты, всё вычитаю. То есть если надо на 1 сентября, вычитаю из текущего остатка всё, что было после первого сентября.

Я тоже в процессинге, от 2 500 000 до 4 000 000 клиентских запросов в день.
100 - 150 Гб оракловых арклогов в сутки.


Я ничего нового не придумал это называется коррелированный (руемый) подзапрос.

Запостил первую ссылку которая попалась в гугле.
Можно поискать более расширенно.

автор
вложенный подзапрос содержит параметр (внешнюю ссылку), передаваемый из основного запроса - номер поставщика P.PNUM. Такие подзапросы называются коррелируемыми (correlated). Внешняя ссылка может принимать различные значения для каждой строки-кандидата, оцениваемого с помощью подзапроса, поэтому подзапрос должен выполняться заново для каждой строки, отбираемой в основном запросе. Такие подзапросы характерны для предиката EXIST, но могут быть использованы и в других подзапросах.

XDiaBLoonstat-автор
вложенный подзапрос содержит параметр (внешнюю ссылку), передаваемый из основного запроса - номер поставщика P.PNUM. Такие подзапросы называются коррелируемыми (correlated). Внешняя ссылка может принимать различные значения для каждой строки-кандидата, оцениваемого с помощью подзапроса, поэтому подзапрос должен выполняться заново для каждой строки, отбираемой в основном запросе. Такие подзапросы характерны для предиката EXIST, но могут быть использованы и в других подзапросах.

Да я в принципе уже понял ваш запрос, а SQL я отлично знаю. У вас там получается после каждой транзакции остаток сохраняется в отдельном поле?

Нет у меня отдельная таблица со ссылкой( FK) на транзакцию и карту или счет,
Но у меня нет FK, потому как ссылка может идти на разные таблицы в зависимости от
других атрибутов.
Например на изменение параметров счета , или лимитов карты.
Каждое изменение - одна строка.

Велосипед на тему аудита в общем.

mikhail_nавторЛично я трубу не создавал

Ну что ж, лавров Н.Е.Жуковского вы себе не приписываете, уже хорошо. Тем не менее, вы не совсем понимаете разницу между автоматизацией работы аэродинамической трубы и численным моделированием течения газа в трубе. Это две совершенно различные вещи.

Разницу я себе представляю.

Автоматизация работы трубы такой же процесс как и автоматизация
контроля и управления толщиной наносимого гальванического покрытия ,
или управление лучем в фазированной антенной решетке
при сопровождении цели локатором.
Все это как и труба связанно с N количеством датчиков и обработкой информации от них.
Мне приходилось работаь по перечисленным. выше темам, но это такой же офтопик как
и труба.
Давайте не будем меряться сами знаете чем. :)