Остатки на дату.

[Владимир Максимов]

Цитата:

Сообщение от mazzy

Я не верю, что для всех аналитик пользователи будут хотеть "получить остатки не в разрезе складской аналитики, а по конкретному реквизиту аналитики"
...
Если ваши пользователи НЕ ХОТЯТ видеть отчет в разрезе всех (или нескольких выбранны) аналитик...

Видимо, мне пока везет (или не везет, это как посмотреть). Но именно это от меня и хотят (или пользователи не хотят)

Хорошо. Если говорить "в общем случае". Почему при расчете остатка на дату от текущей даты назад в разрезе складских аналитик недостаточно будет добавить группировку по соответствующим полям InventDim?

Т.е. логика та же, что и в классе: берем текущий остаток по InventSum, из него вычитаем сумму InventTrans до нужной даты. Это 2 последовательных запроса.

Каждый запрос имеет группировку по нужным полям InventDim.

Какие здесь проблемы? Чем это принципиально отличается от работы классов InventSumDate?

[chel]

Цитата:

Сообщение от Владимир Максимов

Т.е. логика та же, что и в классе: берем текущий остаток по InventSum, из него вычитаем сумму InventTrans до нужной даты. Это 2 последовательных запроса.

Каждый запрос имеет группировку по нужным полям InventDim.

Какие здесь проблемы? Чем это принципиально отличается от работы классов InventSumDate?

При этом подходе основной проблемой будет то, что между запросом к InventSum и запросом к InventTrans (если они будут делаться не по одной номенклатуре, то они будут не очень быстрые), кто-то успеет наделать складских проводок.
Пример из жизни:
1. Исходные данные
Есть одна проводка по номенклатуре 01.01.06 +10 шт
Остаток = 10 шт
Сегодня 31.01.06
2. Начинаем формировать отчет на 15.01.06. Делаем запрос к Sum, получаем 10 шт
3. Кто-то в это время формирует проводку +15 шт
4. Делаем запрос к InventTrans, получаем 15 шт
5. Рассчитываем остатки на 15.01.06: 10шт-15шт = -5 шт
Так что при активной работе с базой этот подход не работает.
А одним запросом при развесистой аналитике - сделать не получится.

[Владимир Максимов]

Цитата:

Сообщение от chel

При этом подходе основной проблемой будет то, что между запросом к InventSum и запросом к InventTrans (если они будут делаться не по одной номенклатуре, то они будут не очень быстрые), кто-то успеет наделать складских проводок.

Вы "вскрывали" код класса InventSumDate?

Там по одному артикулу выполняется несколько последовательных запросов. Все с участием InventTrans. Т.е. Ваше возражение в той же степени применимо и к стандартному классу. Хотя, конечно, вероятность ниже.

Цитата:

Сообщение от chel

Так что при активной работе с базой этот подход не работает.

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

Кроме того, поскольку речь идет о статистических отчетах, то даже если точность в пределах 5%, то считаем, что расчет выполнен точно.

Цитата:

Сообщение от chel

А одним запросом при развесистой аналитике - сделать не получится.

Если я ищу разность данных из 2 таблиц (InventSum и InventTrans), то одним запросом средствами AXAPTA это не получиться в любом случае. Вне зависимости от факт учета аналитики.

То же самое делает и стандарный класс InventSumDate. Но по каждому артикулу в отдельности.

[komar]

Цитата:

Сообщение от Владимир Максимов

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

Это уже целая методология олучения ответа о товарных остатках получается!
Если отчеты выполнять копиях базы, то кроме возникновения необходимости содержать вторую инсталляцию с доступом к ней определенных пользователей (запрещено лицензией!!) также возникнет и вопрос - а зачем тогда вообще использовать промышленные СУБД (на многочисленных копиях базы собирались отчеты с древних версиях 1С и систем на FoxPro лет 10 назад!)

[ALES]

Цитата:

Сообщение от Владимир Максимов

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

Это скорее осутствие "остатков на время"

[ALES]

Цитата:

Сообщение от chel

2. Начинаем формировать отчет на 15.01.06. Делаем запрос к Sum, получаем 10 шт
3. Кто-то в это время формирует проводку +15 шт
4. Делаем запрос к InventTrans, получаем 15 шт

Транзакцию ведь можно и корректно написать

[chel]

Цитата:

Сообщение от ALES

Транзакцию ведь можно и корректно написать

Какую транзакцию? Мы данные получаем в отчете двумя последовательными запросами. Для этого в транзакции, которая выбирает данные, надо установить уровень изоляции "serializable". Разве это можно сделать для одной транзакции в аксапте?

[Recoilme]

Цитата:

Сообщение от chel

Какую транзакцию? Мы данные получаем в отчете двумя последовательными запросами. Для этого в транзакции, которая выбирает данные, надо установить уровень изоляции "serializable". Разве это можно сделать для одной транзакции в аксапте?

Я так понял у Вас MS SQL. =>
Учите мат часть:
1
2
3
4

В аксе используется пессиместическая модель чтения данных, цЫтата из "4":

Цитата:

Пессимистическая стратегия. Основное предположение состоит в том, что T работает параллельно с другими транзакциями, и они ей «мешают». Другими словами, как правило, найдется хотя бы одна транзакция T’, которая изменяет множество чтения и (или) множество записи транзакции T до момента ее фиксации. Все конфликты чтения/записи, ограничения целостности проверяются в процессе работы транзакции T.

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

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

Такой протокол требует наличия механизма блокировок, которые накладываются на объекты данных перед выполнением операции и удерживаются или не удерживаются до стадии фиксации транзакции. Для хранения блокировок требуются дополнительные ресурсы, но наиболее дорогой составляющей частью механизма является проверка блокировок — не заблокирован ли уже тот объект, который собирается блокировать транзакция в данный момент времени. Также необходим компонент обнаружения и разрешения взаимных блокировок (deadlock).

Про версионность пока наверно не стоит заморачиваться

[chel]

Цитата:

Сообщение от Recoilme

Я так понял у Вас MS SQL. =>
Учите мат часть:
1
2
3
4

В аксе используется пессиместическая модель чтения данных, цЫтата из "4":


Про версионность пока наверно не стоит заморачиваться

И чего? К чему эта ссылка и цитата? Мы не можем блокировать InventSum и InventTrans при "пессимистической стратегии", т.к. даже если мы заблокируем изменения, в них легко будут добавляться новые записи (фантомы), от которых уровень изоляции, который применяется в аксапте, не спасет.

Цитата:

Сообщение от Recoilme

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

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

[Recoilme]

Цитата:

Сообщение от chel

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

естественно знаю. И об этом уже сто раз писалось на форуме.

Подходите к менеджерам и объясняете им ЧТО ОСТАТКИ НА ВРЕМЯ - это бред. Т.к. пока они смотрят отчет - остатки меняются. => качаете таблицы в хранилище по ночам и показываете остатки в отчетах из хранилища. Используя ОЛАП или RS. Динамические остатки (на время) - отражаете в формах ввода информации, если это критично им. Например в инвентаризации. На момент разноски/коммита - обновляете. Отчеты такого рода не стоят на "живых базах". Вы просто всё повесите, но никаких некорректностей -не будет. Исключения - для оракл, НО И В ВЕРСИОННОЙ СУБД - вы тоже все повесите. Потому что пока вы будете читать данные - будут плодится версии которые будут тормозить систему. В результате ОРАКЛ/2005 либо отправит вас в сад со своими долгоиграющими запросами, либо Вы снимите Ваш отчет на точку актуальности потратив кучу ресурсов и наплодив кучу мусора. Если конечно у Вас не игрушечная базща данных с миллионом проводок.

[Recoilme]

Цитата:

Сообщение от chel

И чего? К чему эта ссылка и цитата? Мы не можем блокировать InventSum и InventTrans при "пессимистической стратегии", т.к. даже если мы заблокируем изменения, в них легко будут добавляться новые записи (фантомы), от которых уровень изоляции, который применяется в аксапте, не спасет.

Блин... писал писал и не сохранилось. 2 раз ниасилю, поэтому пишу кратко.
0. Выходит я тупой.. потому,что:
1. В одной транзакции читаете с форапдейтом и никаких фантомов у вас не будет.
2. Этот механизм применяется в Аксе повсеместно например при чтении остатков
3. Если бы были какие-то коллизии у вас были бы отрицательные остатки при запрещенном отрицательном складе и т.п. БРЕД у Вас в базе бы был
4. Если у Вас они и есть - это из-за ошибок в алгоритмах, скорее всего Ваших Ошибок В Ваших Алгоритмах, а не фантомов.