Уменьшение кол-ва полей в запросе

[egorych]

Для уменьшения количества полей в курсоре пишу, например так -

    this.itemGroupId      = (select ItemId, itemGroupId, RecId from InventTable
                                where InventTable.ItemId == inventTrans.itemId).itemGroupId;

Но трассировка на сервере говорит, что на сервер уходит запрос с полным перечнем полей, типа так -

SELECT /*+ INDEX(A I_175ITEMIDX) FIRST_ROWS */A.ITEMGROUPID,A.ITEMID,A.ITEMNAME,A.ITEMTYPE,A.PURCHMODEL,A.HEIGHT,A.WIDTH,A.SALESMODEL,A.COSTGROUPID,A.PRIMARYVENDORID,A.NETWEIGHT,A.DEPTH,A.UNITVOLUME,A.BOMUNITID,A.DENSITY,A.DEL_SCRAPTYPEID,A.DIMENSION,A.DIMENSION2_,A.DIMENSION3_,A.DIMENSION4_,A.COSTMODEL,A.USEALTITEMID,A.ALTITEMID,A.INTRACODE,A.DEL_COVPERINVENTLOCATION,A.PHANTOM,A.INTRAUNIT,A.BOMLEVEL,A.BATCHNUMGROUPID,A.AUTOREPORTFINISHED,A.ORIGCOUNTRYID,A.STATISTICSFACTOR,A.ALTCONFIGID,A.STANDARDCONFIGID,A.DEL_CONFIGACTIVE,A.ABCTIEUP,A.ABCREVENUE,A.ABCVALUE,A.ABCCONTRIBUTIONMARGIN,A.COMMISSIONGROUPID,A.DEL_BARCODE,A.DEL_BARCODETYPE,A.CONFIGURABLE,A.SALESPERCENTMARKUP,A.SALESCONTRIBUTIONRATIO,A.SALESPRICEMODELBASIC,A.MINAVERAGESETTLE,A.NAMEALIAS,A.GROSSDEPTH,A.GROSSWIDTH,A.GROSSHEIGHT,A.STANDARDPALLETQUANTITY,A.QTYPERLAYER,A.SORTCODE,A.CONFIGSIMILAR,A.SERIALNUMGROUPID,A.DIMGROUPID,A.MODELGROUPID,A.ITEMBUYERGROUPID,A.TAXPACKAGINGQTY,A.DEL_TEMPLATE,A.WMSPALLETTYPEID,A.ORIGSTATEID,A.STOPEXPLODEPRICE,A.WMSPICKINGQTYTIME,A.TARAWEIGHT,A.PACKAGINGGROUPID,A.SCRAPVAR,A.SCRAPCONST,A.STANDARDINVENTCOLORID,A.STANDARDINVENTSIZEID,A.ITEMDIMCOMBINATIONAUTOCREATE,A.ITEMDIMCOSTPRICE,A.ALTINVENTSIZEID,A.ALTINVENTCOLORID,A.GROSSWEIGHT_RU,A.PACKING_RU,A.ASSETGROUPID_RU,A.ASSETID_RU,A.K_ITEMVIEWID,A.K_ITEMMATERIALTYPEID,A.K_ITEMPRODUCERID,A.K_ITEMCOLLECTIONID,A.K_ITEMCOLORID,A.K_ITEMSIZEID,A.K_ITEMTNVDID,A.K_ITEMREPLACEID,A.K_ITEMDEPARTMENTID,A.EL_1C_COMPATIBLE,A.EN_NAMEALIAS,A.STANDARDINVENTBATCHID,A.ITEMTHICKNESSID,A.SUPPLY_EL,A.SUPPLY_EL2_,A.SUPPLY_EL3_,A.DELIVERY_EL,A.INVENT_NEGATIVESTOCK_EL,A.EL_UZENEN,A.QTYLAYER,A.MODIFIEDDATE,A.MODIFIEDBY,A.CREATEDDATE,A.CREATEDBY,A.RECVERSION,A.RECID FROM INVENTTABLE A WHERE ((SUBSTR(NLS_LOWER(DATAAREAID),1,3)=NLS_LOWER(:in1)) AND (SUBSTR(NLS_LOWER(ITEMID),1,20)=NLS_LOWER(:in2)))

Я помню, было обсуждение - как добиться нужного результата (уменьшение числа полей), но не могу его найти - может кто помнит?

[Vadik]

Цитата:

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

как добиться нужного результата (уменьшение числа полей)

А зачем такого результата добиваться? Выбирается единичная запись по значению первичного ключа в таблице с CacheLookup != None. Такой (и последующие) запросы в основном из кэша AOS-а должны разрешаться без какого-либо трафика вообще между серверами приложений и БД. Хорошо, нет записи в кэше - так надо ее наверное туда поместить, а как это сделать если только часть полей из БД выбиралась?

[egorych]

Не факт, что значение есть в кэше - табличка довольно большая.

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

Цитата:

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

Не факт, что значение есть в кэше - табличка довольно большая.

Вы забываете, что кеш он "общий" и используется многкратно. Уже после того, как его первый раз наполнили.

Предположим, Вы добились чего хотели. Получаем такой сценарий

1. Записи в кеше нет
2. Сделали выборку одной записи, но всего двух полей
3. В кеш записалось только два поля
4. Ваш запрос отработал успешно
5. Теперь Вы делаете выборку других полей
6. Запись уже есть в кеше и Вы берете данные из кеша. Но в кеше есть данные только о тех двух полях, которые Вы выбирали в первом запросе. Получаете проблемы на ровном месте

Т.е. Вам надо либо отменять кеширование, либо выбирать все поля. Что для Вас предпочтительнее решайте сами

[egorych]

Блиин! До чего мне нравятся наши люди! На четко поставленный вопрос дадут жменьку рекомендаций, ЦУ и других полезных вещей! НО НИ СЛОВА ПО ДЕЛУ!
Ну я ж не спрашивал использовать мне кэш или нет! Я хочу, чтобы система не думала, что она умней и делала ровно то, что ей говорят!
Я просил ее выдать все поля? Нет! Так какого-же...

[S.Kuskov]

Цитата:

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

Я хочу, чтобы система не думала...

Отключите кэширование и делов то И не будет система сама принимать решение откуда и когда ей брать значения. Будет написан select - будет сделан запрос в БД

P.S.: На ум пришла одна ситуация для которой данное поведение может быть критично. Это превышение настроенного Maximum buffer size для передачи с клиента на сервер.

[Stitch_MS]

Есть пост на эту тему. Там говорится, что вместо == можно написать like.

[Raven Melancholic]

like проблему выборки полей, конечно, решит. Только вот результат может быть не тот, что хотели получить.
Путь нужна номенклатура 125321, задаем like "125321*", а у нас есть 1253211. Получим непонятно что.

[egorych]

Цитата:

Сообщение от S.Kuskov

P.S.: На ум пришла одна ситуация для которой данное поведение может быть критично. Это превышение настроенного Maximum buffer size для передачи с клиента на сервер.

5 баллов за догадку! Только оно возникает почему-то далеко не всегда и на массовых операциях - типа закрытия склада. Система просто рушится с ошибкой. Причем, Maximum buffer size - это не для клиент-АОС, а для АОС-БД - т.к. в режиме 3-х звенки параметр Buffer size не используется и не доступен для редактирования.

[Stitch_MS]

Цитата:

Сообщение от Raven Melancholic

задаем like "125321*"

зачем?
like вполне себе работает и без звездочек, по конкретному значению

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

Цитата:

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

Блиин! До чего мне нравятся наши люди! На четко поставленный вопрос дадут жменьку рекомендаций, ЦУ и других полезных вещей! НО НИ СЛОВА ПО ДЕЛУ!
Ну я ж не спрашивал использовать мне кэш или нет! Я хочу, чтобы система не думала, что она умней и делала ровно то, что ей говорят!
Я просил ее выдать все поля? Нет! Так какого-же...

Блиин! До чего мне нравятся наши люди! Прочитают только одну фразу ответа и тут же пишут гневные возражения на эту самую фразу. Даже не пытаясь понять о чем вообще речь

Как, ну КАК система должна решить использовать ей кеш или нет? Каким образом она вот здесь должна "думать", а вот здесь - "не думать"? Вы указали ей "не использовать кеш"? Нет! Так какого-же...

А если кеш используется, то автоматически выбираются ВСЕ поля, вне зависимости от того, что Вы там указали.

PS: Каким образом ОДИН запрос поможет решить проблему превышения Maximum buffer size - не понимаю. Ну, вот этот конкретный запрос исправили. И? Ждем следующего падения где-то в другом месте? Так это ВСЮ систему надо перелопачивать на предмет "обрезки" запросов. "Что-то в консерватории надо подправить" (с)

PPS: Кстати, тоже показательно (не знаю, насколько именно для "наших" людей), когда описывают не саму проблему, а выбранный способ ее решения.

[egorych]

Цитата:

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

Как, ну КАК система должна решить использовать ей кеш или нет? Каким образом она вот здесь должна "думать", а вот здесь - "не думать"? Вы указали ей "не использовать кеш"? Нет! Так какого-же...

Согласно МОИМ понятиям - я как раз и указал, что не использовать! Ибо я ПРЯМО указал -"мне нужно ТОЛЬКО 3 поля". Я в курсе, что дамгарды (вместе с мелкософтами) курят другую траву, и их логика с моей не коррелирует, но как еще должно трактоваться ПРЯМОЕ УКАЗАНИЕ - "взять 3 поля" - я не знаю!
Если бы я сначала объявил переменную типа InventTable, потом сформировал кверю или селект, то еще как-то с натяжкой можно смириться с тем, что система правит запрос.

Цитата:

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

PS: Каким образом ОДИН запрос поможет решить проблему превышения Maximum buffer size - не понимаю.

поправка - ОДИН ШИРОКИЙ запрос - запросто может!

Цитата:

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

Ну, вот этот конкретный запрос исправили. И? Ждем следующего падения где-то в другом месте? Так это ВСЮ систему надо перелопачивать на предмет "обрезки" запросов. "Что-то в консерватории надо подправить" (с)

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

Цитата:

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

PPS: Кстати, тоже показательно (не знаю, насколько именно для "наших" людей), когда описывают не саму проблему, а выбранный способ ее решения.

Когда не знают причины - описывают проблему. ИМХО в моем случае - причина очевидна, поэтому я и задал вполне конкретный вопрос.