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

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

Цитата:

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

1. Вы почему то обсуждаете конкретную реализацию, а не принцип. Принцип - считаем проводки от конца, а не от начала времен.

Как минимум, спорный.

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

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

В общем случае, от текущей даты будет быстрее. А в конкретном, надо смотреть на месте.

Цитата:

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

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

Не знаю, у меня как раз пользователи хотят получить остатки не в разрезе складской аналитики, а по конкретному реквизиту аналитики. Т.е. "вообще все остатки вот по этому складу". Просто соответствующий фильтр на InventDim.

Или что Вы понимаете под термином "аналитика номенклатуры" применительно к расчету остатков?

[mazzy]

Цитата:

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

Т.е. "вообще все остатки вот по этому складу". Просто соответствующий фильтр на InventDim.

Или что Вы понимаете под термином "аналитика номенклатуры" применительно к расчету остатков?

Извините. Сейчас используется термин Складская аналитика.
Конурация, Цвет, Размер, Склад, Ячейка, Партия, ... ГТД(!)

Я не верю, что для всех аналитик пользователи будут хотеть "получить остатки не в разрезе складской аналитики, а по конкретному реквизиту аналитики"

Конечно, если у вас используется ТОЛЬКО склад...
Причем НЕ БЫВАЕТ аналитики с выключенным складом (обычно это услуги)...
Если ваши пользователи НЕ ХОТЯТ видеть отчет в разрезе всех (или нескольких выбранны) аналитик...

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

Цитата:

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

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

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

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

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

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

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

[Recoilme]

Цитата:

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

Все равно не понял.
Ну, да ладно. Надеюсь другие разобрались


Искусственные и естественные ключи - это термины.
Поищите. Найдете много интересного.
Поищите на этом форуме для начала. Тема обсуждалась неоднократно.


Они как раз думали.
Просто тогда СУБД были другими.
Тогда приортитеты были другими.
...Тогда - это уже 20 лет назад
http://axapta.mazzy.ru/lib/names/#chronicle

1998 Mar Выпущена система Damgaard Axapta 1.0 - объектно-ориентированная, трехуровневая архитектура клиент/сервер, международная, многопользовательская. MS SQL 6.5, Oracle 7.0

что-то мне подсказывает что в 98 году суррогатные ключи давали 100 очков вперед естественным. Пусть это остается на их совести по крайней мере я в терминологии разобрался

[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 шт
Так что при активной работе с базой этот подход не работает.
А одним запросом при развесистой аналитике - сделать не получится.

[kvan]

Цитата:

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

1998 Mar Выпущена система Damgaard Axapta 1.0 - объектно-ориентированная, трехуровневая архитектура клиент/сервер, международная, многопользовательская. MS SQL 6.5, Oracle 7.0

Аксапта "выросла" из Конкорда, а он появился гораздо раньше 1998 года ...

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

Цитата:

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

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

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

[komar]

Цитата:

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

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

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

[MironovI]

Имхо если есть счастливая возможность брать остатки из ОЛАП то ей грех не воспользоваться, сам так делал,это сильно ускоряет отчет и разгружает рабочую базу, как програмно обратится к кубу можно посмотреть в хелпе по олапу. Только конечно сфера применения узкая - даные не 100% актуальные (кубы считаются с некой периодичностью)..

[ALES]

Цитата:

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

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

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

[ALES]

Цитата:

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

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

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

[Bars]

Цитата:

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

Имхо если есть счастливая возможность брать остатки из ОЛАП то ей грех не воспользоваться, сам так делал,это сильно ускоряет отчет и разгружает рабочую базу, как програмно обратится к кубу можно посмотреть в хелпе по олапу. Только конечно сфера применения узкая - даные не 100% актуальные (кубы считаются с некой периодичностью)..

а можно с этого места поподробнее)

[MironovI]

С какого имено? Примера под рукой сейчас нету к сожалению если вы об этом, давно это было, на пред-пред.. работе, но в общем случае нужно найти в инете odbc-строку подключения.. запрос - можно например посмотреть примеры в mdx sample aplication.. которая в составе olap.. либо ребята с http://www.sql.ru/forum/actualtopics.aspx?bid=26 дожны помоч

[Recoilme]

Хорошая статья про индексный доступ. Интересна с точки зрения понимания принципов работы серверов баз данных. Так как рассматриваемый сервер версионный - есть особенности по сравнению с sql 2000, c другой стороны по сравнению с эскуэль 2005 принципы, по идее, должны быть похожи
описание работы с индексами

[chel]

Цитата:

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

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

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

Рибята, всем низачот

почему никто не предложил считать суммы по периодам, как реализовано для проводок ГК, просто сделать реализацию аналогично классам LedgerBalances* для складских проводок

[Recoilme]

Цитата:

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

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

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

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

Цитата:

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

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

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

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

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

[MironovI]

To Recoilme - Начиная с версии 3.0 все запросы без хита forupdate на скуле выглядят как select from table (nolock) - поэтому для отчетов вопросы с блокировками на запись и чтение не актуальны, поправьте если я не прав..

[MironovI]

Цитата:

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

Рибята, всем низачот

почему никто не предложил считать суммы по периодам, как реализовано для проводок ГК, просто сделать реализацию аналогично классам LedgerBalances* для складских проводок

Я думаю не стоит превращать Аксапту с Один-сами знате какая буква

[kvan]

Цитата:

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

почему никто не предложил считать суммы по периодам, как реализовано для проводок ГК, просто сделать реализацию аналогично классам LedgerBalances* для складских проводок

А кому нужно было предложить?
Те кто понимает о чем речь и так знают, только вопрос такой - во сколько вы оцениваете трудозатраты на такую модификацию?