В особой ценности Embedded SQL я не убежден. Я считаю, что во многих случаях CLI не хуже или даже лучше.

В особой сложности SP у DB2 - тоже. SP у DB2 - это фактически _обыкновенное_ приложение на _обычном_ языке программирования, разве что оформленное так, чтобы его могла вызвать СУБД. (SQL SP транслируется в C). Если вы пишете на Java обычные приложения, для вас не должно быть сложным писать и SP на Java. Если вы пишете на Delphi и при этом достаточно разбираетесь в передаче параметров C и написании DLL, то сможете писать SP на Delphi.

А вот нужны ли вообще SP при работе с DB2, я тоже весьма сомневаюсь.

C MQ Series и менеджерами транзакций мне работать не пришлось (просто не нашел от них никакой пользы в моей текущей работе). VisualAge Smalltalk отличается от Delphi в плане работы с DB2 наличием static SQL (отличий, конечно, много, но в данном контексте важно только одно), в ценности которого я совсем не убежден.

DB2, конечно, монстр, и с каждым годом становится все толще. Лично я начал бы уже не добавлять, а убирать из нее некоторые фичи (наподобие структурных типов). Но по сравнению с Oracle она просто худышка.

А в некотором смысле я назвал бы ее самой простой. Это связано с оптимизатором, мощнейшим диалектом SQL и советчике по созданию индексов. Чтобы ярче выразить свою мысль, предлагаю вспомнить, как пользователи MySQL мучаются от отсутствия вложенных select'ов. Да, во многих других СУБД вложенные select'ы есть, но их SQL все равно убог по сравнению с DB2-шным. Оптимизатор и index advisor упрощают настройку производительности прямо-таки фантастическим образом. Для сравнения, когда я сдуру, поверив одной статейке про Oracle, будто в 8-й версии они наконец сделали cost-based оптимизатор, собрал статистику по таблицам в имеющейся у нас системе, некоторые запросы перестали работать, а некоторые стали выдавать неправильные результаты!!! Меня тогда чуть инфаркт не хватил, сутки разбирались с разработчиками, пока один не догадался поинтересоваться, не собирал ли я статистику. Пришлось ее очистить, и все заработало как надо. Порядок таблиц в запросе, создание индексов - все вручную. С DB2 же можно просто оттрассировать SQL-выражения и получить рекомендацию по созданию индексов. Понятно, что на создании нужных индексов настройка не кончается, но облегчение огромное.

В версии 8 обещали также автоматизировать создание Summary Tables (почему переименовали Index Advisor в Design Advisor), но пока этого нет. Вещь очень полезная (один из запросов при использовании Summary Table у меня ускорился в тысячи раз), и не сомневаюсь, что она будет реализована в одном из будущих фикспаков, потому что официальный курс IBM - на упрощение администрирования и самонастройку СУБД.

2 Guest123:

* "применение СУБД DB2 на реальных проектах из реальной жизни не имеет существенных преимуществ перед конкурирующими продуктами других фирм" - а как же, например, упомянутые мной cost based optimisation и Index Advisor?
* "Инструменты, которые бы мне помогли реализовать бизнес-логику приложения как разработчику в DB2 не лучше, но значительно сложнее чем у основных конкурентов." - не вижу, чтобы она была сложнее Oracle (который я тоже администрирую), а SQL (http://ourworld.compuserve.com/homepages/Graeme_Birchall/HTM_COOK.HTM) дорогого стоит, и вообще, уточняйте, о каких инструментах идет речь.
* Я не понимаю, что такое "идеология применения".
* Про хранимые процедуры я "в курсе" лишь относительно, поскольку их не применяю, но, насколько я помню, есть средства для копирования SQL SP с сервера на сервер без перекомпиляции; кстати, если на сервере будет правильно установлен "правильный" C-компилятор, процесс будет совершенно прозрачен для программиста, он выполняет CREATE ... и т.д., а все остальное (включая компиляцию) идет без его участия;
* На Workgroup Edition цены понижены, на Enterprise Edition - (к сожалению) повышены;
* "Зачем понижать цены, если не лучше" - так что, советуете повышать?

2 NewYear:

Application Development Client (бывший SDK) отродясь (или, по крайней мере, с версии 2.1 до версии 7.2) был бесплатным. Правда, на download'е для 8-ки его сейчас нет, но жду с очередным фикспаком на ftp.software.ibm.com.

На DB2, как я слышал, работает Пенсионный фонд.

Ходят слухи ;-), что те слухи, что DB2 будут переводить на Informix'овый движок - полная фигня. На самом деле Informix будут держать до тех пор, пока большинство пользователей на DB2 не переведут. Ну, что-нибудь из Informix'а и выдернут, но вряд ли много.

Не вижу причин, по которым доминошные приложения _придется_ переписывать из-за DB2. Так просто не делается, никто из мало-мальски вменяемых фирм на такое не пойдет. Вы будете точно также оперировать документами и полями, а "под ковром" будет не обращение к файлу, а выполнение SQL-выражения, но для разработчика это абсолютно прозрачно.

Между прочим, я так на Smalltalk'е работаю. SQL не пишу, чисто smalltalk'чьи выражения. Генерация SQL возлагается на TOPLink.

The following example of a block expression selects all employees that live in the same city as their manager from the table:

aDatabaseSession readAllFor: employee where: [:eachEmployee | eachEmployee address city = eachEmployee manager address city]

This translates into the following fairly complex SQL statement:

SELECT E1.*FROM Employee E1, Employee E2, Address A1, Address A2
WHERE
(A1.city = A2.city) AND
(E1.address_id = A1.id) AND
(E1.manager_id = E2.id) AND
(E2.address_id = A2_id)

Что именно не выйдет?

Например: Получить список документов? Найти документ по ID? Добавить новое поле? Элементарно. [Очевидно, одному документу может соответствовать несколько записей в нескольких таблицах].

А большее домине вряд ли и надо.

Кстати, NewYear, какого-такого прекомпилера в WE нет? Все на месте.

Дешевая WorkGroup Edition - это хорошо. А версия под Линух, по слухам, даже вдвое дешевле прочих (это специальная промоушн-скидка).

2 Guest123: "(К примеру простой сценарий из жизни моей конторы: есть центральная СУБД которая свзана асинхронной репликацией с СУБД в куче филиалов (несколько десятков). Нужные данные реплицируются туда и обратно. Если разработчики центральной СУБД меняют ХП процедуру, то она реплицируется в филиал(ы). Если измения серьезные - ты присылается скрипт, который и делает все необходимое. Здесь налицо преимущества инфраструктуры Sybase). "

Интересный момент. У Sybase есть уже готовая репликация не только данных, но также изменений структур данных, хранимых процедур и т.д.??? Если нет, в СУБД есть только готовая репликация данных, а репликация изменений структур и SP сделана разработчиками базы (не СУБД, просьба их не путать), то от ситуации с DB2 это ничем не отличается.

Вообще, для более плодотворного обсуждения предлагаю:

* Сделайте маленькую тестовую базку на Sybase (такую, какую, по вашему мнению, вам удобно делать на Sybase и неудобно на DB2) и опубликуйте скрипты здесь, а мы обсудим. (Я наверняка предложу заменить SP на VIEW и триггеры).

* Сообщите, чего вам не хватает на Sybase (наверняка ведь чего-то не хватает, идеальных вещей ведь нет), и мы обсудим, нет ли этого у DB2.

Скажите еще, что все языки программирования одинаковы, и все равно, на чем программировать. (А ведь можете и сказать, если знакомы только с "наследниками Алгола", т.е. C-подобными и паскалеподобными, и больше ничего не знаете, но будете неправы).

Особые преимущества _возможны_ (скорость, кстати, не самое главное), только вот на продаваемость они влияют слабо.

Между SP и продвинутым SQL разница огромная, пусть они и решают те же самые задачи. Упрощенный пример (для понимания, в чем разница):

CREATE VIEW V1 AS
SELECT ... FROM T1
UNION ALL
SELECT ... FROM T2;

Некоторые так называемые SQL-сервера (не буду показывать на них пальцем) неспособны даже на это (VIEW c UNION ALL внутри). Хорошо, это решаемо при помощи некоей хранимой процедуры P1, которая как-то выходит из положения, типа - открыть курсор на одной таблице, потом на другой, или забабацать содержимое обоих в явную или неявную временную таблицу (на разных по разному).

Продолжу пример. Теперь я в DB2 выполняю запросы типа
SELECT ... FROM V1 WHERE fname = 'Иван'
или
SELECT ... FROM V1 WHERE lname = 'Иванов'

В процессе построения плана, DB2 эти запросы перепишет, типа

SELECT ... FROM T1 WHERE fname = 'Иван'
UNION ALL
SELECT ... FROM T2 WHERE fname = 'Иван';

SELECT ... FROM T1 WHERE lname = 'Иванов'
UNION ALL
SELECT ... FROM T2 WHERE lname = 'Иванов';

Какие мы имеем преимущества:
1. Каждая секция UNION ALL может оптимизироваться отдельно и выполняться параллельно;
2. Явная подстановка параметров, благодаря чему оптимизатор, зная распределение по колонке fname, прикинет, какое количество записей приблизительно можно ожидать и какой нужно использовать индекс (и нужно ли это вообще). Надо сказать, что "некоторые" SQL-сервера на такое просто неспособны и для SELECT ... FROM T2 WHERE fname = 'Иван' приведут его в вид SELECT ... FROM T2 WHERE fname = :parameter, построят план для этого запроса и подставят в параметр 'Иван'.

Как поступит "некоторый сервер" c хранимой процедурой (SELECT ... FROM P1 WHERE fname = 'Иван'), если такая конструкция вообще для него возможна? Не думаю, что об этом нужно говорить. В реальности программист "некоторого сервера", скорее всего, вместо одного DB2-шного VIEW будет вынужден писать несколько хранимых процедур, с ужасными конструкциями во WHERE (:param1 Null or fname = :param1) AND (:param2 is null or lname = :param2) внутри, или кучей IF-ов (потому несколько SP, что на каждое сочетание параметров в одной SP все равно невозможно предусмотреть).

А всякие там курсоры живо навевают мне воспоминания о клипперовских временах. Один крЮтой ораклист меня особенно потряс, ему надо было посчитать количество записей в таблице, удовлетворяющих некоему условию, так он сделал так - открыл курсор на запросе типа select 1 ...where условие и прокатился по курсору, увеличивая счетчик ;-)... но если подумать, то другой код других (профессиональных, опытных) ораклистов, который я видел, не сильно-то лучше.

Да, Sybase вплоть до 12.5 (проверять не стал, но страница 121 в SQL User Guide гласит - "You cannot use the union operator within a create view statement.") - я не знаю, существует ли более поздняя версия Sybase и как там обстоят дела, и Interbase до 5.5 - я не знаю, как с этим обстоят дела в 6-й версии.

Но мой пример не про наличие/отсутствие UNION во VIEW, а про пользу продвинутости SQL и оптимизатора и вред хранимых процедур. Наверняка можно придумать и другие примеры, уже без участия UNION, но мне так было проще всего.

Я не то что бы ратую за DB2, потому что техническое превосходство - чуть ли не самый последний фактор из влияющих на популярность и рынок, но хочу показать, что своя ниша у нее таки-есть.

Да если хотите, можете просто сравнить

(вариант 1)
CREATE VIEW V1 AS
SELECT ... FROM T1
UNION ALL
SELECT ... FROM T2;

(вариант 2)
с хранимой процедурой, выполняющей

SELECT ... FROM T1
UNION ALL
SELECT ... FROM T2;

и возвращающей result set. Суть моего примера не изменится. Хранимая процедура - лишняя работа и потенциальные тормоза.