Ggg_oldКогда я предлагал создать этот топик очень надеялся, что появится человек, который объяснит инженерным языком, в каких случаях и на каких задачах более сложное программирование на EmbedSQL оправдано. Я действительно не понимаю, зачем писать на EmbedSQL, при наличии более человеческого способа работы с базой. И судя по всему остальный считают также (ИМХО).
ESQL очень даже удобно, код гораздо читабельней, чем через компоненты, плюс во время его компиляции ESQL сразу же проверяется на сервере, параметры легко передавать, получать прямо в переменные, обьявленные в коде, легко вызывать ХП, организовывать локальные курсоры по полученным наборам данных с запросов и ХП, и т.д. Все это, например, есть в PowerBuilder, причем в нем ESQL не заточен под определенную СУБД, а работает под поднятой сверху сессией/сессиями, которые могут идти через ODBC, ADO, OLEDB, ADO.NET, JDBC, ...

gardenmanВложенный SQL плохо (отвратительно) реализован в MSSQL, Sybase ASE, PostgreSQL, MySQL(нет вообще). Про Sybase ASA - ничего не могу сказать (не смотрел) но думаю ASA не далеко ушла от ASE. Относительно приемлемо реализован а Oracle, и нормальня реализация - только в DB2.
Сам я с реализацией ESQL в ASA не работал, так как считаю дурным тоном рисовать клиентские мордочки на C, но думаю что судя по описаниям ESQL и примерам кода в BOL, его реализация в ASA более чем удовлетворительная ;)

gardenmanУ DB2 (как правило) - получается статический SQL с уже предопределенным планом запроса. Скорость выполнения выше в разы. Вот и получается, что статический SQL помноженный на производительность C++ - дает бешенную производительность.
Вы уже не впервый раз сохранение плана запроса при компиляции ХП выдаете за этакое преимущество, что вот мне совершенно не понятно. Есть у меня БД девелоперов, она находится в разработке и содержит достаточно небольшое кол-во тестовых данных, охватывающих различные аспекты ТЗ с целью наиболее удобного тестирования бизнес-логики. После проведения изменений в ней корректирующие SQL скрипты уходят на консолидированную БД с требованием выполнится на ней и всех удаленных узлах (БД). Естественно консолидированная БД содержит информацию всех узлов. Далее после проведения сеанса репликации каждый удаленный узел так же получает корректирующий скрипт и выполняет его, помимо обычного сеанса приема/передачи изменений данных. Узлов у нас например 500. Все идут через оффлайн (почта, ftp, файловый обмен - без разницы). На каждом узле информация, принадлежащая только ему. Соотвествующе на одном узле большая БД, на другом крохотная, на одном например стоит навороченный сервер под UNIX, на другом обычный PC с W2K Prof. Внимание вопрос - это интересно как же это при компиляции ХП на девелоперской БД с учетом ее "левых" данных мы обеспечим бешеную производительность для консолидированной БД и ее удаленных узлов ? Божьим духом, принудительной перекомпиляций скриптом или запиской для "опытных" пользователей - типа войди и перекомпилируй и будет тебе счастье (причем на Си) ?

Мне кажется привязка планов к ХП есть зло, нормальная РСУБД должна сама соображать, какие планы для текущей БД на текущей момент времени оптимальны, автоматом вести статистику, корректируя ее по мере необходимости, наилучшие планы запросов не только кидать в кэш, но и записывать с кешем в БД для быстрого их подьема для быстрого рестарта сервера, а так же иметь эвристический анализатор, у которого хватает ума усомнится в актуальности "наилучших" планов и не поленится заново понастроить планы и сравнить их с используемыми, чтобы в случаях резкого изменения содержания информации (например массовый подлив данных), не просесть в лужу. Во всяком случае в Sybase ASA все это делается автопилотом, если у меня оптимизатор правильно "понимает" как я связываю в сложных запросах и в наличие удобные индексы, то это его уже проблемы, какие он планы будет строить и что там будет использоваться.

Кстати все вышесказанное к Sybase ASA в полной мере относится и к серверу Sybase IQ, который в отличие от ASA, заточеннуб для SMB, "ориентирован" на нулевое администрирование аналитических БД больших обьемов.

Так что пожалуйста уж поясните свои высказывания, почему круто писать ХП на Си, да еще и компилировать прямо в них планы запросов ? В плане скорости я отметаю сразу - в ASA например планы ХП компилируются при первом к ним обращении после запуска сервера (если их еще нет в сохраненном кэше), причем они не привязываются к ХП, а висят как просто планы к запросам, которые вызываются в том числе и из ХП. Время построения плана запросов занимает миллисекунды (если конечно не вывести уровень компиляции с нормального 9-ого уровня на максимальный 15, что уже будет соотвествовать полному перебору всех возможных видов планов запросов) - так что проблем со скоростью построения планов лично я ни разу не наблюдал, у Watcom всегда были неплохие скорости в различных решениях :)