forum.clarionlife.net

kreator писал(а): Я бы пошёл по всем проводкам и раскидывал бы товар в очереди товаров.

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

kreator писал(а):

finsoftrz писал(а): А можете определить в Вашей системе, например, сколько маржи получилось по конкретному поставщику за прошедший квартал?

Поставщиков нет. Контора производственная. Себестоимость продукции считается отдельно. Маржа - типа разница между себестоимостью и оптовой ценой.

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

kreator писал(а):

Игорь Столяров писал(а):Да. Но это будет список с уникальным индексом (например для остатков: предприятие, склад, товар, дата),по которому будет производится выборка. Никто ведь не собирается последовательно "лопатить" весь этотсписок при каждом запросе на остатки ...

Тема складского учёта - безразмерная. Давайте отвлечёмся от хранения итогов. Допустим без итогов пока. И, допустим, у нас файл-сервер. Как посчитать остатки. Я бы пошёл по всем проводкам и раскидывал бы товар в очереди товаров. Второй вариант - идти по проводкам по индексу товара. Вы как считаете? А если итоги хранятся где-то, то второй вариант предпочтителен?

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

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

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

Тогда надо начинать с "руды", как хранятся данные. Слово "мапить" не понимаю. Для увеличения быстродействия в файл-серверных БД часто пользуются "избыточностью" информации. Подозреваю, это и есть денормализация. Да?

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

Получается, что Вы храните остатки всех наименований по всем складам, по магазинам, по поставщикам, покупателям?

kreator писал(а): Тогда надо начинать с "руды", как хранятся данные. Слово "мапить" не понимаю. Для увеличения быстродействия в файл-серверных БД часто пользуются "избыточностью" информации. Подозреваю, это и есть денормализация. Да?

Денормализация в данном случае - это сохранение некоторых значений из заголовков накладных в строках детализации, чтобы можно было построить эффективный индекс. Под мапить я подразумеваю следующее. У Вас, скорее всего, документы и их строчные части хранятся в отдельных таблицах. Кроме них еще есть большая таблица операций (проводок), которая заполняется по мере сохранения документов в базе данных. Или несколько таких таблиц по назначению. У меня только таблицы документов. И служебные таблицы остатков/оборотов, заполняемые по мере закрытия периодов и необязательные для использования.

kreator писал(а):

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

Получается, что Вы храните остатки всех наименований по всем складам, по магазинам, по поставщикам, покупателям?

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

PS. А у Вас формируется план платежей поставщикам с учетом отсрочек и возвратов? Тоже полным перебором считаете?

Да, я всё считаю полным перебором. И, кстати, опт и розница присутствует. Когда-нибудь нужно будет задуматься об итогах. Либо (что более вероятно) задуматься о другом железе. До "Big Data" ещё далековато. Видите, Вы же сами подтверждаете, что и то и то нужно хранить. Потребуется какой-нибудь специфический отчёт в каком-нибудь разрезе, нужно будет задуматься о хранении промежуточных итогов для нового отчёта. Вот что мне не нравиться. Время разработчика уходит не туда.

А почему не туда? Насколько я видел, большинство учетных систем хранит итоги. Делать эти итоги только можно по разному...