Цитата:
Сообщение от
egorych
Только вряд-ли там будет написано - "дети, используйте курсоры на сервере и будет вам щасте"
Попробуйте на любом форуме по MSSQL показать трассировку запросов и послушайте, что вам скажут на счет разработчиков.
Когда-то давно, когда я только начинал Аксаптой заниматься, SQLные админы фыркали, мол "Эта ваша аксапта курсорами пользуется". У меня, надо сказать, это фырканье вызывало некоторое недоумение и вот почему: Моим первым SQL-базой данных был Informix, после этого я с Oracle работал и достаточно мало с MS SQL. А в Informix, курсор был просто некой внутренней переменной (на самом деле структурой сишной), которая в прикладной программе использовалась для доступа к результатам выборки. Ну то есть - кроме как через курсор до результатов выборки никак не добраться. При этом где-то в документации говорилось, что мол скорее всего под курсор будет создана временная таблица на сервере, но если запрос простенький (типа select * from table where indexField=константа) или курсор не навигационный (fast forward), то сервер постарается временную таблицу не создавать. И я сначала просто не понимал о чем эти сиквельные админы говорят. Потом выяснилось что в MS SQL есть, грубо говоря, два метода доступа к данным. В первом из них (без использования курсоров) на сервер просто отправляется запрос, и потом клиент должен прочитать выборку сверху-вниз (естественно можно прервать процесс и не читать выборку до конца). Во втором из них (как раз с курсорами) - сервер создает временную таблицу, в которую результаты запроса и складываются. В этом случае - возможно применение навигационных операций к результатам запроса, ценой большей нагрузки на сервер.
Тут надо сделать некоторую интерлюдию, заметив что во времена проталкивания на рынок клиент-серверной архитектуры, отцы-основатели рассказывали что в светлом комму^H^H^H^H^H клиент-серверном будущем, с системой будут работать исключительно сферические пользователи в вакууме, которые перед каждым открытием, ну например, формы номенклатурного справочника, будут весело и радостно указывать номенклатурную группу, фильтр по коду и названию номенклатуры, в общем прилагать все усилия для того чтобы выборка не превышала пары экранов. А любые предположения о том чтобы побровситься по таблице будут вызывать у этих пользователей гневное отторжение, и они будут устраивать демонстрации у местного представительства провинившегося вендора, крича "Курсоры - геть !" и размахивая транспарантами с надписью "FORWARD_ONLY".
Естественно, при столкновении с реальной жизнью всем вендорам пришлось рано или поздно обзавестись навигационным доступом (у оракла он, кстати, только в версии 9 появился). Естественно - у всех СУБД навигационный доступ обходиться дороже чем ненавигационный, но иначе пользователей не удовлетворить.
В принципе, я могу согласиться с тем, что для небольших таблиц (скажем - настроек профилей разноски) можно было бы не использовать курсоры, а просто вытаскивать таблицы в кэш напрямую. Но поскольку таблицы эти и так небольшие, большого накладяка от курсорного доступа к ним нету. В общем - могу предположить, что в будущих версиях аксапты, для таблиц с fullTable cache сделают выборку без курсора (поскольку курсор там и вправду смысла не имеет). С другой стороны - есть сильнейшее подозрение что заметного выигрыша это не даст...
Теперь немножко о том, что было бы если бы аксапта ПОЛНОСТЬЮ отказалась бы от использования курсоров. Я когда-то занимался развертыванием версий 2.5 и 3.0 на Оракле. Поскольку и та и другая версия должны были поддерживать Оракл 8ой версии, scrollable курсоры, появившиеся в версии 9i в них не использовались (Кстати - не знаю, используются ли они в более поздних версиях Аксапты, сам на оракле не внедрял, а спросить не у кого
). Последствия применения чистого ненавигационного доступа в этих версиях аксапты на оракле можно было простейшим экспериментом. Надо было открыть какую-нить достаточно большую таблицу (ну скажем inventTable), нажать на кнопку PgDn и подержать достаточно долго, чтобы система отлистала страничек 30-40. Далее надо было нажать кнопочку PgUp и попытаться отскроллиться назад на начало таблицы. При этом возникал любопытный эффект: Странички на 3-4-5 назад можно было отскроллиться быстро, после чего система впадала в спячку секунд на 10, снова быстро скроллила 3-4-5 страничек назад и тд. Происходило при этом следующее: Система доставала из буфера несколько страничек, потом буфер кончался. Ну а поскольку оракл в те времена не поддерживал навигационного доступа, аксапта просто переоткрывала запрос с ноля и фетчила те 25 страниц, которые отделяли ее от нужной записи таблицы. Хотя, конечно, пользователи на этот эффект натыкались не очень часто, но время от времени, случались жалобы на тему того что система вдруг заткнулась на 10-15 секунд.
Ну и наконец - где-то в документации Оракла, английским по белому сказано что при использовании scrollable cursor, сервер БД сохраняет результаты выборки в области памяти, а если выборка большая, то во временной таблице. Что в общем, мало отличается от поведения серверных курсоров SQL Server.
Так что избавиться от курсоров, на самом деле, можно но только
1. Для случая маленьких таблиц и нормальных пользователей.
2. Для случая любых таблиц и сферических пользователей в вакууме.
P.S. Просьба модераторам дискуссию по поводу курсоров и вообще MS SQL vs Oracle вынести в новый топик.