|
17.10.2006, 12:07 | #1 |
Участник
|
в классах все прекрасно, НО я так и не могу понять никак одну вещь. а именно...
Во всех классах этих используется ItemId, так вот где его брать??? мне что перебирать ВСЕ номенклатурные единицы и подставлять в этот класс??? БРЕД. Тогда получается надо делать while select... по таблице InventTrans или InventSum c ограничениями по складу и по МОЛу, и потом передавать в класс... НО какой тогда в этом смысл, если все сводится все равно к запросу по одной из таблиц? |
|
17.10.2006, 12:23 | #3 |
Участник
|
|
|
17.10.2006, 12:39 | #4 |
Участник
|
Цитата:
Не видите вигрыша в производительности между перебором в таблице номенклатур и в таблице проводок? Ну, как скажете. Согласен с glibs. |
|
17.10.2006, 12:45 | #5 |
Участник
|
эээ, не совсем так поняли я не вижу смысла особого в использовании классов когда скажем дата достаточно поздняя, получается тоже самое (если не хуже) что и ограниченный запрос по складским проводкам, хотя... конечно спорно все это... эмпирика нужна ...
|
|
17.10.2006, 13:04 | #6 |
Участник
|
Цитата:
Причины: 1. "Дата достаточно поздняя" у вас находится близко к началу только потому, что вы недавно начали. Через пару лет даже очень поздние даты в 99.9% случаев будут находится очень далеко от первых проводок 2. Один "ограниченный запрос по складским проводкам" блокирует на чтение очень большой набор записей. Скорее всего, на очень долгое время (пока работает отчет). Блокировки одного ограниченного запроса очень быстро будут эскалированы на всю таблицу. В результьте одного "ограниченного запроса" очень велика вероятность deadlock'ов и того, что остальные не смогут работать "очень долгое время". Один ограниченный запрос может дать выигрыш в однопользовательских системах И практически никогда не дает выигрыша в многопользовательских. |
|
17.10.2006, 13:26 | #7 |
Участник
|
Цитата:
Сообщение от mazzy
Нет, не то же самое.
Причины: 1. "Дата достаточно поздняя" у вас находится близко к началу только потому, что вы недавно начали. Через пару лет даже очень поздние даты в 99.9% случаев будут находится очень далеко от первых проводок 2. Один "ограниченный запрос по складским проводкам" блокирует на чтение очень большой набор записей. Скорее всего, на очень долгое время (пока работает отчет). Блокировки одного ограниченного запроса очень быстро будут эскалированы на всю таблицу. В результьте одного "ограниченного запроса" очень велика вероятность deadlock'ов и того, что остальные не смогут работать "очень долгое время". Один ограниченный запрос может дать выигрыш в однопользовательских системах И практически никогда не дает выигрыша в многопользовательских. респект |
|
17.10.2006, 16:21 | #8 |
Member
|
Цитата:
Сообщение от mazzy
...
Один "ограниченный запрос по складским проводкам" блокирует на чтение очень большой набор записей. Скорее всего, на очень долгое время (пока работает отчет). ... Насколько я знаю, Аксаптовские отчеты (и формы тоже) используют грязное чтение и ничего не блокируют обычно (если в классе не наваять чего-нибудь для расчета данных для отчета, да еще и не обрамить это в транзакцию). По крайней мере на MS SQL так. Но если речь идет о создании строк журнала, то, скорее всего, выборка попадет внутрь транзакции и будет блокировка на чтение (или как там оно называется). Так вот будет ли разница в плане блокировки между одним большим запросом и перебором в рамках одной транзакции InventTable и расчетом остатков с помощью классов? Вопрос скорее общетеоретическо-блокировочный, нежели в рамках описанной выше задачи. Если кто может просто ссылку привести, где это на уровне домохозяек прописано, то это тоже будет хорошим ответом.
__________________
С уважением, glibs® |
|
17.10.2006, 12:11 | #9 |
NavAx
|
|
|
17.10.2006, 12:24 | #10 |
Участник
|
|
|
17.10.2006, 12:39 | #11 |
Member
|
Цитата:
Сообщение от sparur
...
мне что перебирать ВСЕ номенклатурные единицы и подставлять в этот класс??? ... Если нужны текущие остатки, то брать только не закрытые физически. Если остатки на дату, то все.
__________________
С уважением, glibs® |
|