Весьма рекомендую Quest Central. Существенно приличней, чем то, что есть у самой IBM

ТВВ
Смысла сравнивать нет, он работает только с DB2,
схема интерфейса примерно такая же как у MS EM,
только по функциональным возможностям он наверно покруче будет, так как есть у него еще несколько приятных дополнительных фишек, которые впрочем,
у MS реализуются дополнительными утилитами, речь
идет о миграции БД. Он мне собственно для этого и
понадобился, а потом просто привык

На www.quest.com есть триальная версия.

To: gardeman
Администрирование БД не есть ее проектирование.
В первую очередь администрирование связано:
1) Управление правами доступа
2) Настройкой режимов работы сервера БД
3) Управление сохранением/востановлением БД
4) А есть еще управление репликациями, проблема миграции БД и еще, еще, еще....

Боюсь, что не одно средство проектирования БД не справиться с этой задачей. А что касается конкретно
DB2, то в связи с ее спецификой, например хранимых
процедур, то и полностью промоделировать ее в неродных
средах невозможно, увы это так.

Так что я думаю у Quest Central еще долго будет и на хлеб,
и на масло

to gardeman.
Ну эту технологию мы в общем то используем.
Замечу, что здесь все немного сложнее, чем вы описали.
Все сказанное Вами справедливо, но только для
случая использования в храниых процедурах статических
SQL операторов, они действительно генеряться в пакеты,
причем, при пересборке процедуры, им по умолчанию
дается новое имя, и в результате, мы имеем совершенно
конкретный геморой, по их администрированию. Мы даже
вынуждены были написать свой тулз, по раздаче прав.
А ведь есть еще хранимые процедуры на java, которые
как правило используют динамический SQL, пакетов они
не генерят, и пользуются правами, данными для таблиц.
Т.е. если пользователь таблиц не видит, такие процедуры работать не будут. На мой взгляд, родная система администрирования DB2 весьма архаична и неудобна.
Думаю, что сказывается наследия майнфреймов, когда я думаю пакеты оформлялись отдельным набором перфокарт.

to gardeman
Вы затронули черезвычайно интересную тему, я бы даже
сказал сакральную. Действительно, есть ли такие
программы, которые нельзя было бы написать на ассемблере ??? И чего эти парни суетяться и суетяться,
выдумывают всякую фигню. Насчет легкой переносимости
на СИ, я бы не был так уверен. Просто, наверно, вы еще
на эти грабли не наступали. А у меня было, несколько раз
и на разных продуктах. Для каждого инструмента характерна та, или иная технология. Каждая технология имеет свои плюсы, и свои минусы. Если у технологии нет
плюсов, она умирает. Плюс динамического запроса в том,
что его можно формировать на этапе выполнения, черезвычайно мощный и удобный механизм. Минус, в невозможности его оптимизации. Наверно все таки можно
придумать задачу, которую можно решить динамическим запросом, и невозможно статическим, я на эту тему особенно никогда не заморачивался.
Интересный разговор получился, а начиналось все так невинно, с проблеммы администриролвания :))

Ну вопрос о переносимости - он на самом деле мифологический,
правильней наверно говорить о миграции, естественно, это процесс,
сопровождаемый определенными усилиями. Размер этих усилий зависит
от 2-х факторов.
1-й, то, что реализованно на более простом инструменте, на более сложный
переноситься легче.
2-й, более сложный фактор, перенос между тождественными архитектурами
происходит легче.
Я, совсем недавно, например, споткнулся на переносе с платформы Intel на
платформу Sun, DB2 V7.1. Пришлось попотеть, хотя на 100% проблема полностью так и не решилась.

Насчет задачи - ну я думаю это такие задачи, в которых запрос возникает
в моменте выполнения задачи. Придумать, честно говоря прямо сейчас мне
немного некогда, но где нибуть в январские каникулы, я попробую
такую задачку сформулировать.

vasilis:
Ну с этой то частью понятно. Речь то шла о хранимых процедурах, вряд ли целесообразно ее создавать для выполнения сиюминутной, одномоментной задачи. Тут лучше воспользоваться соотвествующим инструментом, хотя конечно можно и самому написать. Вопрос шел о том, есть ли такая задача, которае требует использования динамического SQL в хранимой процедуре, и которую нельзя решить средствами статического SQL.
Как вариант такой задачи предлагаю задачу управления доступа к данным через View, который генериться в момент вызова хранимой процедуры, в зависимости от объема прав, предоставленных пользователю на данный момент времени, при этом предполагается ограничения не только по колонкам, но и по строкам. Наверно такую схему решить через статический запрос сложновато.

Victory
Хочу выступить в защиту хранимых процедур. Сама по себе очень полезная технология, которая позволяет четко локализовать код. Скажем мы создали некий объект, который реализован посредствои нескольких таблиц БД. И хотим естественно получить несколько методов работы с этим объектом. Очень удобно это делать через хранимые процедуры. Исли это делать через SQL операторы, то они расползаются по приложению, и при изменениии объекта, а это неизбежно, нужно будет лазить по приложению и менять эти операторы, процедура в этом плане значительно стабильнее. Скажем, если я в объекте Документ, провел номализацию, и вынес атрибут Тип документа в отдельную таблицу, то теперь запрос выборки у меня поменялся, он основывается на соединении 2-х таблиц, хотя с точки зрения возвращаемого набора данных ничего не изменилось. Используя хранимую процедуру, я имею локализованный код по получению, например списка документа, и поправив процедуру, я в приложении вообще могу ничего не менять. Ну это к слову. А вообще за год разработки мы написали около 200 хранимых процедур, и этот механизм нас здорово выручает, особенно при написании отчетов.