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 всегда были неплохие скорости в различных решениях :)

gardenmanНа счет хранения планов я могу сказть, что как правило существует наиболе оптимальный план выполнения запросов, не зависящий даже от статистики.
если рассмативать что-то типа:
select * from A,B where A.a=? and A.id>=? and b.id=a.id order by A.a,A.id
fetch first 50 rows only
то естественно нужно построить два индекса A(a,id) и B(id) (если B- какой-то справочник для A), то неужто нужно чтобы оптимизатор срабатывал для таких запросов? Для таких вещей лучше раз и навсегда построить план и не мучать систему, особенно, когда таких запросов приходят пачки за секунду.
Такие примитивные запросы разве что клиентские приложения посылают. Они оседают в кэше оптимальных планов, раз строятся и работают. Если информация кардинально изменилась, планы перестраиваются, оседают в кэше и снова наступает затишье без перекомпиляции.

gardenmanА разве ни у кого не бывало так, что по мере наполнения базы данных вдруг
(даже при актуальной статистике) все начинает тормозить, появляются tablescan или порядок соединения в запросе меняется?
Честно говоря, оптимизатор - вещь хорошая, но я слегка нигиллист, и не могу полностью на него положиться. А если планы перестраиваются часто, - их трудно контролировать. Например если дабавил какой-то индекс на таличку, то по идее оптимизатор должен перестроить планы. А мне это не всегда нужно. Изменилась статистика - опять перестроить. Что в результате получится - я не знаю. Конечно можно просто положиться на оптимизатор, но у кого нет ошибок?
Ну во первых в результате добавления, изменения индексов/статистики не факт, что оптимальные планы будут перестроены - с чего бы это вдруг, если существующие в кэше отрабатывают в разумное время ? Во вторых для действительно сложных запросов с использованием параметров планы будут разные в зависимости от значения этих параметров - где то выгоднее индекс, где то хэш-соединение, а где то и Table Scan. Причем планы могут получатся кардинально разными, соединения в них между таблицами/процедурами не будут статичны в плане, а значит статически сгенерить и запомнить план, который бы подходил для любого случая в жизни да еще и для любой БД с своей информацией по моему не реальная задача. В третьих извиняюсь, если один и тот же запрос/представление/ХП используется в других запросах, которые могут быть как OLTP с различными уровнями изоляции (что актуально для блокировочников), так и OLAP с нарастающими функциями (те же Window функции), то и тут планы запросов могут кардинально отличаться, в ASA при построении планов запросов оптимизатор учитывает не только момент как быстрее выполнить, но и как не просадить выполнением сервер по отношению к другим сессиям в отношении ресурсов и блокировок и где например, несмотря на наличие более удачного индекса предпочтение может отдасться PK или Unique только из за того, что запрос выполняется на высшем уровне изоляции и уникальный индекс позволяет снизить нагрузку на блокировки в плане ресурсов и деятельности других сессий.

gardenmanДа и вы сами знаете что все планы выполнения просмотреть иной раз невозможно. Я предпочитаю знать что и как у меня обрабатывается в системе и не пускть это дело на самотёк. Это вообще что-то из темы - почему откомпилированное (в машинные коды естесс-но) приложение работает быстрее чем интерпретируемое или откомпилированное в байт-код.
В жизнь не поверю, что в DB2 нет профайлера ХП, консультанта индесов и дебаггера. Запускаем профайлер, он собирает статистику по выполнению всех ХП, триггеров и функций, далее визуально видим полный список того, что выполнилось, сколько в процентном и временном отношении это заняло, соотвествующе тормозные ХП при сортировке по времени выполнения будут стоять первыми в гриде. Далее опять же в профайлере уже по коду этих ХП по строкам смотрим время и процент выполнения и сразу же видим запросы которые тормозят. Далее по желанию - можем запустить консультант индексов, который во время реальной работы БД соберет всю информацию по выполненным с ХП запросам и на каждый запрос даст рекомендации по недостающим/лишним индексам, показав тут же план запроса "Как есть" и "Как может быть". Или же в дебаггере на этих тормозящих строчках в ХП шлепнем бряк-пойнты, выполним их, остановимся в нужных местах и вполне культурно тут же в дебагере повыполняем запросы из этих ХП, посмотрим их планы, статистику, значения глобальных и локальных переменных, посоздаем виртуальных индексов и посмотрим насколько они нравятся оптимизатору, ну и т.д. По моему так или иначе любая РСУБД имеет более чем достаточно средств для мониторинга и профайлинга выполнения запросов и ХП, разве что у кого то удобнее, у кого то не так удобно сделано.

gardenmanА вообще я не понимаю зачем вы приплели сюда репликацию? Она тут вообще нипричем.
А затем, что репликация тоже дает нагрузки на сервер, особенно если ей сказано не протоколировать действия триггеров и ХП, а дублировать на консолидированных/удаленных БД их вызовы. Надо думать здесь тоже начинает работать оптимизатор и для каждой БД план запросов для ХП и триггеров может отличаться и при выполнении репликации.

Гм, отсюда пару моралей (конечно лично моих и спорных с точки зрения специалистов других РСУБД):
1. Оптимизатора не нужно боятся, его нужно понимать и вести совместную работу, как партнером, который конечно же тоже может ошибаться и подвести.
2. Для серверов, ориентированных на распределенную работу с множеством удаленных точек, как самостоятельных серверов посредством репликаций, правила игры будут одни (это нулевое администрирование всех частей СУБД), для тех, у кого решения базируются на централизованной работе правила игры могут быть другими (думаю тут впервую очередь будет идти масштабируемость, гибкость настроек и скорость работы). Может быть здесь статическая компиляция планов/статистики и прокатит, в моих решениях на ASA кроме геммора бы она ничего не принесла, поэтому я очень рад, что ее в природе не существует :)