Магазин
А как у агрегируются данные(Приходы, продажи) за прошедшие периоды (допустим за прошлый год)?
Никак. Структура базы данных оптимизирована настолько хорошо, что ни один из наших сетевых розничных клиентов не помышляет об обрезании базы данных. То есть, спустя годы после начала учета вы будете видеть данные за эти годы с той же производительностью, что и за последнюю неделю (период охвата отчета, конечно, на скорость расчета влияет).
Если возникают сомнения в содержательности хранимых данных, то сообщаю, что храняться все чеки (со строками), операции по дисконтным картам, учетные документы (формируемые по результатам списания кассовых сессий), естественно, приходы, прочие расходы, межскладские перемещения, инвентаризации, производство, бухгалтерия (включая проводки по всем учетным документам), управление проектами, задачами. Короче, все, что можно (зарплаты пока в функционале нет).

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

PS
Для наиболее приставучих клиентов (обычно оптовых торговцев) реализована процедура усечения базы данных. Она сама по себе совершенно корректная, но пользоваться мы ею никому не рекомендуем из-за того, что пропадает радость обладания учетными данными за большой период работы.

Pervasive.SQL
Если быть предельно точным, то чистый Btrieve.

HHD
Если это не "секретная разаработка", подскажите, пожалуйста в общих чертах структуру БД. Просто интересно, ведь объемы данных достаточно большие, особенно в рознице, и без некоторой аггрегации тяжеловато высчитывать исторические данные за прошлые периоды.
Разработка не секретная, но не OpenSource. К сожалению, мы структуру данных не публикуем. Хотя какие там секреты - гсподин Кодд все расписал. Плюс немножко мозгов в организации индексов и экономное отношение к размерам записей.

Кстати, о структуре данных. Если вы скачаете демо-версию, то структура словаря данных как на ладошке (средствами Pervasive SQL).

Сергей Васкецов

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

PS. Потрясающая грубость накануне новогода.

Модератор: цитата вырезана

Александр Федоренко
Вот уж геморой на всю оставшуюся жизнь этой программы..

Очень сильное утверждение

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

Очень малорепрезентативный пример:
1. Время расчета сильно зависит от железа
2. В бытовой технике из нескольких тысяч наименований активно юзается малая часть (поднимите ABC-анализ)
3. Количество транзакций значительно ниже чем, скажем, в продуктовой торговле
Да и вообще, глупо меряться линейками заочно.

Александр Федоренко
Да нафиг меряться, просто привел реальный пример. Количество товарных позиций имел в виду уже в отчете. Поднимать анализ мне не надо - это ж жизнь моя (была..). тысяч 8 всего, из них половина живых. Крупный поставщик, практически весь спектр бытовухи. Опт и мелкий и практически до розницы во "встройке" например. Но с Ашаном не сравнить, это точно :) Сервер порядка 10к $. В системе все товарные и финансовые оперции.
Боюсь показаться голословным (нет под рукой похожей ситуации), но не думаю что ваш результат необоримый.

Сергей Васкецов
А это не агрегат по-вашему? Чистейшее хранение исходящего сальдо на момент транзакции.
Агрегат так агрегат. Прения по терминологии? Я полагаю, что агрегатное значение есть результат операции над множеством записей (суммирование операционных величин по всем записям с начала периода, например). В том случае, о котором я говорю, значение остатка берется из хронологически предшествующей записи и к ней прибавляется операционное значение создаваемой записи (впрочем, вы это и сами знаете). Еще раз, не стану возражать если вы назовете это так, как вам больше нравится.

Сергей Васкецов sobolevзначение остатка берется из хронологически предшествующей записи и к ней прибавляется операционное значение создаваемой записи
Вот это и есть тонкое место в Вашей реализации.
1. Необходимо как-то найти предыдущую запись (какая запись предыдущая? а если набор аналитик, по которым предыдущая запись определяется, расширится?).
2. Необходимо вставить новую, причем так, чтобы следующая запись не успела подумать, что для нее предшествующая - это уже неактуальная предшествующая, а только что вставленная новая. То есть, фактически в Вашем случае требуется обеспечить блокировку как минимум индекса, как максимум - таблицы.

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

Мне затруднительно вдаваться в глубокую дискуссию из-за дефицита времени, плюс к тому,
насмотревшись на этот форум, я могу с уверенностью сказать, что с этим сообществом затруднительно спорить (это - не претензия к сообществу, скорее - сетование на собственную неспособность адаптироваться к жанру). На более-менее конструктивные вопросы отвечу с удовольствием.