Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / IBM DB2, WebSphere, IMS, U2, etc Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2      [все]
 Особенности DB2 - в чем цимус?  [new]
Guest123
Guest
Всем привет.
Пару дней как начал изучать DB2. Изучаю исключительно для собственного самообразования и расширения кругозора(пока). Основная СУБД на работе - Sybase. Если можно, то я задам несколько общих вопросов знатокам DB2 и несколько конкретных.
Общие вопросы
1)Интересно узнать какие критерии кроме ("у нас тут мэйнфреймы...","это в натуре круто", "за нее за бугром платят много денег, а я хочу туда уехать","хотелось выпендрится") рассматривались в вашей фирме, при выборе СУБД в пользу DB2. Почему спрашиваю - уж очень этот продукт не популярен в наших краях, значит есть причина. Все говорят, что DB2 не уступает Oracle, но Oracle судя по кол-ву сообщений в форумах Оракла и ДБ2, то .....
2) Stored Procedures.
Как я понимаю, то весь свой Сайбэйзовый в этой области опыт тут неприменим.
Все процедуры пишутся как программы, компилируются, подлинковываюися к базе. Все процедуры кроме Java-овых являются платфомозависимыми. Процесс написания даже самой простой процедурки с ее отладкой очень усложнен.
Я попробовал сделать SQL-процедуру (Language SQL) но она не захотела Build в базу, т.к. не на машине установлен VisualC. Java SQLJ процедура скомпилировалась успешно.
Как-бы все понятно, но непонятно главное - ЗАЧЕМ такие мучения, ради чего и что это дает вообще?. Чем технология организации процедур DB2 лучше чем у того-же Sybase?. То, что время разработки приложений значительно возрастает видно сразу, что квалификация разработчика требует хорошего знания JAVA, C, тоже видно, но вот какое конкурентное преимущество это дает мне не ясно.
Конкретные:
- Можно ли посмотреть план выполнения SQLJ Stored процедуры, при вызове ее через CALL?
- после создания Stored процедуры в Stored Procedures Builder и ее успешного Build, эта процедура не появляется в списке Stored Procedures у этой Базы в Control Centre, хотя она выполняется успешно.

Пока все. Большая просьба, не воспринимать этот топик как критику или наезд или попытку нахваливать другие СУБД. Просто помимо деталей реализации чего-то в кокретной системе, хочется понимать для чего это нужно, почему сделано именно так, где и для чего именно эта система применяется успешнее других.

Всем спасибо.
alexcey@mail.ru
16 дек 02, 10:29    [91339]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
прикинь, у меня тоже на работе сейчас главная СУБД -Sybase ASE 12.5 ))
Вообще по Sybase с удовольствием пообщался бы, если будет такая возможность. Особенно интересно то каким образом под Sybase пишете приложения. Вообще - порядок разработки.
А вот что касается DB2 _ работал (на предыдущем месте работы) лет 5...) начиная с DB2 v 2.1 под OS/2 (тогда еще NT не было)
Могу сказать одно - если хотите писать хорошие приложения на DB2 - используйте Embedded SQL. В противном случае никакой выгоды от DB2 не получите.
Последня версия DB2 просто великолепно поддерживает C++. Например в Sybase с этим - большие проблемы (( там токлько ANSI С. А встраивая SQL прямо в C++ код я получаю просто фантастическую выгоду. (У Sybase втроенный SQL реализован очень плохо..просто на порядок ниже чем у DB2)
В DB2 можно передавать host-переменную по ссылке, делать выборку сразу в структуру. Тем кто пишет на C++ - это очень удобно.
Есть такая вещь, как идеология применения сохраненных процедур. Исходя из способов разработки которые предлагаются Sybase и DB2 - естественно сохранёнки применяются по-разному. Если будет желание, то могу прислать маленький проектик, реализованный на VC++/ DB2
пишите: fouga@progress-neva.ru
16 дек 02, 12:34    [91501]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
petrofff
Member

Откуда:
Сообщений: 18
Работаем уже наверно года 3.
Реально никаких особых преимуществ не видно. Разве что работает в общем то
довольно быстро, оптимизатор запросов у них хороший. Ну наверно еще, как плюс, довольно тонкое управление, например дисковым пространством. На мой взгляд, преимущества появляются когда ты начинаешь использовать всю линейку технологии IBM. Причем желательно на монстровых проектах, скажем, ежели у тебя клиентов хотя бы пару тысяч, и база распределенная (как мне один мен объяснял, у меня грит один сервер в Хельсинке, другой в Курске), вот тут и выясняется, что реальных конкурентов окажется не так уж много. Объясняю более конкретно. Скажем ты используешь, кроме самой DB2, еще и MQ Series, монитор транзакций, технологию VA (скажем генератор + смалтолк), то она (энта технология) почти сама, организует и гарантированную доставку транзакций, и платформенно независимые формы, и путем простой пересборки проекта менять архитектуру от майнфрейма до N уровнего, короче полный атас, ежели ты конечно от всего этого не охренеешь (шутка) На локальном проекте (я думаю для IBM это все, что меньше 100 пользователей) реальных преимуществ не видно. Хотя работать можно.
Короче, меня тут правда уже по этому поводу немного опустили ниже плинтуса, вопрос не в СУБД, вопрос в технологии. И технологию от IBM нужно
расматривать в комплексе. Сама эта технология (это мое приватное мнение) тяжеловата, и для легких проектов ее использование наверно не целесообразно, но наверно самая масштабируемая.
25 дек 02, 04:18    [96585]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
В особой ценности 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 - на упрощение администрирования и самонастройку СУБД.
21 янв 03, 10:56    [110741]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
mahoune
Member

Откуда: Moscow
Сообщений: 5663
Сразу видно DB2 используют люди серъезные и целеустремленные. Все посты длинной не меньше километра
21 янв 03, 12:21    [110889]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
Guest123
Guest
Судя по ответам можно подбить предварительный итог:
- применение СУБД DB2 на реальных проектах из реальной жизни не имеет существенных преимуществ перед конкурирующими продуктами других фирм. - Инструменты, которые бы мне помогли реализовать бизнес-логику приложения как разработчику в DB2 не лучше, но значительно сложнее чем у основных конкурентов.
- четкой и не очень идеологии примения DB2 в ответах лично я не увидел. Кто является потребителем этого продукта? Я на сайте IBM не нашел документов, вкоторых бы прописывалась аудитория потребителей ее СУБД с описанием сценария, качества и характеристик задач, для решения задач которой DB2 проявляет себя лучше всего (кроме Build your Operational Data Strore).
(К примеру простой сценарий из жизни моей конторы: есть центральная СУБД которая свзана асинхронной репликацией с СУБД в куче филиалов (несколько десятков). Нужные данные реплицируются туда и обратно. Если разработчики центральной СУБД меняют ХП процедуру, то она реплицируется в филиал(ы). Если измения серьезные - ты присылается скрипт, который и делает все необходимое. Здесь налицо преимущества инфраструктуры Sybase). Как например такое делается на DB2 я пока слабо представляю (особенно с перекомпиляцией хранимых процедур).

А теперь почему я собственно поднял эту тему. Конечно, можно было бы сказать, что DB2 - это настолько в натуре круто, что простому инженеру ее не дано понять. Эта система юзается только "взрослыми пацанами" во "взрослых" комапниях зарубежом. Тогда с этой точки зрения, можно согласиться - что рынок IBM - это миллиардные сделки с ведущими компаниями мира, а вы так сказать "рыломс не вышли".
Но тогда мне непонятно:
- чем вызвано снижение цен на DB2v8 до уровня цен напрямую конкурирующей с MSSQL2000 и Sybase (например 7500баксов за Workgroup edition c безлимитным кол-вом подключений), как желанием закрепится на этом (самом массовом) сегменте рынка? Если их СУБД не лучше уже зарекомендовавших себя конкурентов- то зачем все это?
- зачем эти программы обучения молодых специалистов на решениях IBM, если этот специалист все-равно выберет не DB2?
- зачем российское представительстово IBM сeществует вообще, если наш бизнес просто не дорос до их "крутой" DB2?
- ну и последняя "наболевшая" причина, ради которой я и взялся ковырять DB2. DB2 - как будущая платформа для следующей версии LotusDomino. Я например просто не представляю среднестатистического разработчика LotusNotes/Domino, который клепает и компилирует, компилирует, перекомпилирует на VisualC процедуры (или агенты), для простых в операций над документами.

Вот в общем такие мысли. Жду "раздалбывающей" меня критики. Пишите в форум.
21 янв 03, 18:28    [111569]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
NewYear
Member

Откуда: Большой адронный коллайдер
Сообщений: 2203
ну ты вааааще. 2 дня назад начаизучать db2. ты хоть бы пару проектов сделал. для приличия.

а ты вообще-то видел инструменты разработки? у меня, например VisualAge Generator. покажи мне хоть что-нибудь похожее :)

говоришь, Workgroup Edition дешевая? так в ней прекомпилера нет. к ней придется покупать еще что-нибудь.
Development Client или Enterprise.

кто заказчик? МПС, например. они колесные пары учитывают (на мэйнфрейме, естественно).
попробуй сделать это на Sybase. колесных пар много.

или, взять хотя бы аэску. я под нее год писал, и она за это время ни разу не подвисла.
работает как часы. а сколько Sybase проработает?

и что ты озабочен процедурами? раз ты начал писать процедуры, ты завязался на базу.
с Sybase уже не слезть - ни на db2, ни куда-то еще. пользуйтесь серверами приложений, сэр.

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

черт, мне домой пора
21 янв 03, 22:33    [111691]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
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 - (к сожалению) повышены;
* "Зачем понижать цены, если не лучше" - так что, советуете повышать?
22 янв 03, 14:34    [112328]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
2 NewYear:

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

На DB2, как я слышал, работает Пенсионный фонд.
22 янв 03, 14:43    [112359]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14266
А вроде слух ходят что ИБМ в ДБ2 собираются использовать Информиксовский движок?

ИБМ по-моему давно переросла свои размеры и разные её части занимаются разными вещами независимо друг от друга. Мне, вот, тоже интересно, что они с Доминой сделают. Насколько я знаю, планируется полностью отказаться от .nsf и перейти на нормальный сервер (ну, наверно ДБ2) - т.е. 100% гарантии что все приложения придётся переписывать. В принципе, всё правильно, тока делать это надо было сразу после 5 версии. Или даже вместо неё.
22 янв 03, 15:05    [112397]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
Ходят слухи ;-), что те слухи, что 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)
22 янв 03, 16:20    [112540]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14266
Э нет, с Доминой так не выйдет. Только в каких-нить простых вещах.
Хотя... Посмотрим.
22 янв 03, 16:33    [112558]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
Что именно не выйдет?

Например: Получить список документов? Найти документ по ID? Добавить новое поле? Элементарно. [Очевидно, одному документу может соответствовать несколько записей в нескольких таблицах].
22 янв 03, 16:37    [112565]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
А большее домине вряд ли и надо.
22 янв 03, 16:38    [112569]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
Кстати, NewYear, какого-такого прекомпилера в WE нет? Все на месте.

Дешевая WorkGroup Edition - это хорошо. А версия под Линух, по слухам, даже вдвое дешевле прочих (это специальная промоушн-скидка).
23 янв 03, 11:16    [112999]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
Victor Metelitsa
Member

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

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

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

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

* Сообщите, чего вам не хватает на Sybase (наверняка ведь чего-то не хватает, идеальных вещей ведь нет), и мы обсудим, нет ли этого у DB2.
23 янв 03, 11:32    [113017]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
NewYear
Member

Откуда: Большой адронный коллайдер
Сообщений: 2203
хз.
вот лежит у меня на столе килограмм дисков с дб2.
Схватился я за диск нечаянно и поставит не ту редакцию.
смотрю - а там db2 prep не работает.
23 янв 03, 12:52    [113210]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
NewYear
Member

Откуда: Большой адронный коллайдер
Сообщений: 2203
о, диск с Personal Edition нашел.
может, я и не прав насчет WE ....
просто у меня Enterprise, и я чегт знает что про Workgroup подумал.
23 янв 03, 13:05    [113227]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
NewYear
Member

Откуда: Большой адронный коллайдер
Сообщений: 2203
но пересталлять db2, чтобы убедиться, не буду
23 янв 03, 13:07    [113234]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
petrofff
Member

Откуда:
Сообщений: 18
По поводу особых преимущест. Их нет ни у какого производителя. Скажем, если вдруг, случилось чудо, и DB2 на той же платформе стало крыть например ORACLE раз в 10, то все бы долларами проголосавали за DB2, это форпрос чисто экономический. Реально мы видим колебания рынка в ту, или иную форму. Причем, чисто технические характеристики тут не всегда являются определяющими. Ну скажем Lotus 1-2-3, был в свое время лучше Excel, но был вполне успешно задавлен Мелкософтом, а вот с Lotus у них не получилось, хотя такая компания разворачивалась, не получилось потому, что Lotus прикупило IBM, и борьба стала бессмысленной, у IBM бабок не меньше, чем у Гейтса. Определяющим является фактор привычки, если ты на чем то долго работаешь, то все альтернативные решения принимаются с трудом. Опять же на некоторые вещи можно смотреть по разному. Например, нафиг мне хранимые процедуры, если у меня такой продвинутый диалект SQL, альтернативный взгляд - потому такой продвинутый SQL, потому что механизм хранимых процедур очень слабый. Факт один, а интерпретация разная.
Ну конечно есть еще личные предпочтения, мне например нравился Informix. Главное в этом деле не доходить до фанатизма, и объективно оценивать более сильные, или более слабые стороны продукта.
24 янв 03, 04:27    [113858]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
Скажите еще, что все языки программирования одинаковы, и все равно, на чем программировать. (А ведь можете и сказать, если знакомы только с "наследниками Алгола", т.е. 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 условие и прокатился по курсору, увеличивая счетчик ;-)... но если подумать, то другой код других (профессиональных, опытных) ораклистов, который я видел, не сильно-то лучше.
24 янв 03, 12:02    [114118]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
Roman Pankov
Member

Откуда: Moscow
Сообщений: 79
Некоторые так называемые SQL-сервера (не буду показывать на них пальцем) неспособны даже на это (VIEW c UNION ALL внутри).

А почему бы и не ткнуть... "Имя, сестра, имя!"... ;)

Только что проверил:
MS SQL Server 2000 - способен
Informix DS 7.3 - запросто
Oracle 8i 8.1.7 - без проблем
за DB2 вы вроде как и сами ратуете, но я проверил - и убедился, что все в порядке

Sybase?... Interbase?...
24 янв 03, 15:56    [114487]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
Да, 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, потому что техническое превосходство - чуть ли не самый последний фактор из влияющих на популярность и рынок, но хочу показать, что своя ниша у нее таки-есть.
24 янв 03, 17:54    [114649]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
Да если хотите, можете просто сравнить

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

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

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

и возвращающей result set. Суть моего примера не изменится. Хранимая процедура - лишняя работа и потенциальные тормоза.
24 янв 03, 18:18    [114664]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
NewYear
Member

Откуда: Большой адронный коллайдер
Сообщений: 2203
а я знаю, где в какой базе нельзя использовать union во вью. в DB2 for S/390 вплоть до шестой версии. :) (в седьмой можно)

только вопрос возникает - что, кому-то понадобился такой вью? по-моему, этот пример хорош только в обучающих целях. с практической точки от него мало толку.

зато DB2 на мэйфрейме-самая быстрая база. а это вполне аргумент в пользу DB2 :)
24 янв 03, 18:36    [114677]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
Guest123
Guest
Всем спасибо за конструктивную критику. Немного эмоциональный постинго у меня получился, за что и получил. Постараюсь исправить свои заблуждения. Теперь по поводу хранимых процедур. Честно говоря я надеялся, что мне доступно объяснят в чем преимущество наличия только extended SP в DB2, и как это классно сопрягается с задачами, которые в основном крутятся на ней. Вместо этого меня пытаются убедить, что можно жить без процедур вообще. Хмм. Даже не знаю, что и сказать. Во всех книжках пишут для чего нужны ХП, для чего нужны VIEW, Triggers. И замена одного из этих инструментов другими как правило к хорошему не приводит. Приведу пример одной процедуры, которую недавно писал и задам вопрос - как такое нормально можно сделать на VIEW+Triggers?. Есть таблица платежей с полями Дебет,Кредит, Сумма. Задача выбрать все платежи с реквизитами кредит заданными списком, дебет заданными списком. Упрощенно процедура должна выбирать все платежи между двумя группами клиентов, где счета входящие в группы задаются из-вне и заранее неизвестны. Я для этого сделал ХП, в которую передаются две строки. Каждая из этих строк содержит счета группы разделенными запятыми. Эти строки внутри процедуры парсаются и значения заносятся в соответствующие временные таблицы. После чего просто производится выбор строк из таблицы платежей, счета дебет которых есть в во временной таблице счетов дебета,
счета кредит в таблице счетов кредита.
26 янв 03, 23:03    [115043]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
pauel
Guest
Dumaju cht zameniv UNION ALL na prosto UNION sdelaet spisok "nel'zja" esche bol'she, i deistvitel'no - a zache takoe VIEW.

Tema, v celom, interesnaja, no mne "za bugrom" ne ponjatnaja :

samolet - letit,
mashina - edet.
DB2 - na mainfraime.

Po drugomu ne videl (v real'nih "production" systemah).

I tut deleju VB programni, kotorie est' -"clients" for DB2. No DB2 na mainframe, a dlja soedinenija vb(PC) s DB2(mainfraim) mi ispol'zuem "DB2 connect"( IBM pruduct) ili "Host Integration Server" (from Bill). I nikogda ne stojal vopros perestavit' DB2 kudanibud'.
26 янв 03, 23:25    [115045]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
petrofff
Member

Откуда:
Сообщений: 18
По поводу хранимых процедур. Я могу привести и другой пример, когда реализация на хранимой процедуре и проще и эффективней. Связан он с формирование отчетов, когда процедура формирования выборки для отчета и процедура его форматирования различаются по числу вызовов.
Далее, я конечно всегда восхищался умельцами, который пишут SQL запрос на 3 - 4 страницы, и для модификации которого, в случае ухода такого умельца, необходимо 3 - 4 дня. Кроме индивидуального мастерства, важен еще и факт стоимости владения такой штукой. При промышленной работе, коглда например вопросы кодирования и проектирования разнесены, важно иметь более легкий в понимании, реализации и модификации код. Увы, но большая часть например наших проектироващиков мыслит императивно. Т.е. последовательными категориями. В этом плане хранимая процедура проще для понимания. Конечно, за все надо платить, как правило такие решения менее производительные. Но зачастую лучше иметь вовремя не оптимальное решение, чем оптимальное, когда оно не нужно. Есть еще и один чисто прагматический взгляд. Чем это хуже решение, когда есть возможность использовать 2 механизма. Т.е. логика такая: этого механизма нету, потому что мне это не надо, и это хорошо,что то непонятно. Непонятно также и почему, в таком случае IBM от версии к версии пытается улучшить механизм хранимых процедур. Межлу прочим разница между 6 и 7 версией колосальная, наверно не знают уроды, что нафиг это не нужно :))
27 янв 03, 09:46    [115125]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
Guest123, а вы все-таки почитайте книжку с http://ourworld.compuserve.com/homepages/Graeme_Birchall/HTM_COOK.HTM. Поинтересуйтесь конструкциями выборок, начинающимися с WITH, особенно главами Recursive SQL и Fun with SQL. Временные таблицы _прекрасно_ эмулируются внутри DB2-шного запроса (и даже VIEW).

Триггеры, кстати, можно считать одним из видов SP, но более удобным - вызываются неявно и всегда, обойти нельзя. В 8-ке появились триггеры INSTEAD OF.

Еще один довод против "настоящих" SP - GUI builder'ы (точнее, библиотеки, которыми они пользуются) и генераторы отчетов обычно знают о таблицах, колонках, первичных ключах, ингода об автоинкрементных колонках, но не в состоянии заглянуть во внутрь хранимых процедур.

В книжках, да, пишется, "зачем" нужны SP, но примеры обычно... сомнительные. Сейчас перечитываю одну переводную книжонку про Oracle - это ж настоящий позор, такие примеры. По-моему, всё там выражается без процедурных конструкций (хотя не обязательно одним SQL-оператором), обычно короче и наверняка быстрее выполняется.
27 янв 03, 10:03    [115144]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
2 petroff.

Приводите свой пример.

Нормально написанный запрос на выборку хорошо пишется, читается и понимается, даже если большой. Он выглядит как последовательность VIEW, что тут сложного-то?

Не вижу никакой "колоссальной разницы" в SP между v6 и v7. А IBM ведет себя так, как должна вести себя приличная фирма: если пользователи это хотят, то они это получат, даже если, по большому счету, они вполне могли бы без этого обойтись. Кроме того, некоторые фичи вводятся, облегчить миграцию с других SQL-серверов. Поэтому, к примеру, есть теперь и автоинкрементальные поля, и sequences одновременно.
27 янв 03, 10:43    [115186]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
NewYear
Member

Откуда: Большой адронный коллайдер
Сообщений: 2203
2 Guest123
реквизиты, говоришь, приходят извне?
что проще, чем засунуть их в систему. заведи таблицу, что ли :) за одно и историю получишь. а дальше-клавиатуру в руки и вперед. а места для процедуры я в упор не вижу.
27 янв 03, 14:20    [115455]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
NewYear
Member

Откуда: Большой адронный коллайдер
Сообщений: 2203
Sorry, вижу -- распарсить строки :)
применение интересное, хотя почему бы и нет.
я бы, наверно, сделал это на клиенте. отдельной кнопкой 'Import xxx to zzz'.
27 янв 03, 14:33    [115470]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
Guest123
Guest
Еще есть один довод в пользу ХП - Безопасность БД.
Я всегда следую принципу:
- пользователи имеют доступ к БД только через ХП. пользователи не имеют никакого права на объекты БД кроме как права выполнять доступные им ХП.
- доступ к объектам БД на SELECT, должен даваться только некоторым пользователям и на непродолжительное время и только в качестве исключения.
Такой подход спасает от гигантского кол-ва проблемм. Например изменить право доступа к таблице в Sybase ASA если эта таблица кем-то используется просто нельзя. Если таблица БД постоянно занята, то ждать можно очень долго.
Есть еще плюс - управляемость режимом использования БД. Например, если небходимо модифицировать процедуру во премя работы БД или запретить в определнное время суток выполнять некоторую работу с БД, то достаточно забрать права доступа на определенные процедуры у юзеров и все. Или еще такой сценарий: есть OLTP база. В ней две процедуры - одна делает транзакции - добавляет/изменяет записи в таблице. Другая процедура делает жуткую выборку и лочит эту таблицу. (конечно не хорошо смешивать OLTP и DSS в одной базе, но если сервер один то надо выкручиваться) Необходимо, чтобы пользователь мог выполнять обе операции, но в определенное время дня выполнять процедуру на выборку прав не имел, дабы избавить базу от тормозов. Правами на таблицу здесь ничего не сделаешь. Ну про вариант, когда обну стандартную процедуру используют несколько разных приложений (например под WEB, Delphi, LotusNotes) даже и говорить нечего. Не писать же в каждой апликухе один и тот-же запрос.
Кстати, очень интерестно услышать мнение публики на правильность применения такого приема: вызов внутри ХП запроса, который формируется динамически самой ХП c с помощью функции sp_execsql (MSSQL точно такое дает сделать).
27 янв 03, 15:27    [115540]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
NewYear
Member

Откуда: Большой адронный коллайдер
Сообщений: 2203
ну и что? чем права на процедуру отличается от прав на вью в плане функциональности? конечто, проблема с локировками существует и в DB2 (только под платформу AS/400, там grant на вью зто grant на logical file, и никакой атрибут файла нельзя изменить, ести тот открыт). решается просто:
поддерживать 2 системы,
test environment и productional environment. все эксперименты - в тесте. я если кто вздумает что-то менять в productional, да еще и во время работы системы -- в лучьшем случае можно побить, в худшем--уволить.

доступ к обьектам на непродолжительное время у меня по крайней мене вызывает недоумение.
получаеся, что в кто-то меняет productional систему во время работы.

жуткие выборки в определенное время огранизуются вообще просто: в системе должен быть планировщик. жуткое прилжение, которое составляет отчет(например) планируется для выполния ночью.
сценарий примерно таков:
c 00.00 гасится подсистема QINTER(напиши свое название) гасится. как следствие, все пользователи отваливают. затем подсистема QNIGHT поднимается, и приходит время ночных джобов. резултаты ночных джобов где-то сохраняются(если они нужны)
в 06.00 -- обратный процесс :)


Ну про вариант, когда одну стандартную процедуру используют несколько разных приложений (например под WEB, Delphi, LotusNotes) даже и говорить нечего. здесь ты прав. и нахрена столько одинаковых приложений?
27 янв 03, 17:33    [115657]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
Guest123
Guest
Спор о том что нужнее VIEW или ХП и без чего можно обойтись мне кажется неперспективным. Если условия задачи позволяют использовать VIEW, то можно
использовать VIEW, если удобно работать с ХП, то надо юзать ХП (пример процедуры я привел выше). А упорствовать в борьбе за VIEW против ХП глупо, кстати как и наоборот. Кстати,в LotusDomino вся идея доступа к информации построена на VIEW, ну нету динамических запросов на выбор документов и все. Но от этого функционал не страдает.
27 янв 03, 18:18    [115710]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
NewYear
Member

Откуда: Большой адронный коллайдер
Сообщений: 2203
нее, еще не все... еще можно писать под мониторы транзакций, еще бывают сервера приложений... вот тогдо то ХП оказываются вообще в ...
27 янв 03, 18:50    [115731]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
С невозможностью сменить права я у DB2 как-то не сталкивался; вообще, правильно написанное приложение для серверов-блокировочников (DB2, Sybase, MS SQL...) должно коммититься как можно чаще (если только иное не обусловлено логикой), ибо и SELECT порождает блокировки.

Запрет на выполнение VIEW может быть встроен в сам VIEW (поскольку мы во время выполнения запроса можем

* узнать время, когда он исполняется
* выбросить исключение, если время "не то"

но вообще, лучше прочитайте в руководстве DB2 про Governor. "Ну про вариант, когда обну стандартную процедуру используют несколько разных приложений" - как будто для VIEW это не так.

Я с DB2 Common Server/DB2 UDB вожусь уже много лет, и, раз средство (SP) есть, я _хотел_ его применить. Но так и не смог! ;-) Не придумал, зачем. Одна только процедурка проработала относительно недолгое время (sequences эмулировал, хотя и здесь в конечном счете обошелся без нее). Минусы, они как на ладони, а плюсов так и не увидел.
27 янв 03, 19:29    [115748]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
golsa
Member

Откуда: Красноярск
Сообщений: 789
Прения на тему: что лучше View или SP не состоятельны.
Я бы еще понял, если бы вопрос стоял так: где лучше исполнять модули (EXE или DLL) на клиенте, на сервере приложений или на SQL сервере.
SP оформляется как DLL на SQL сервере (для WinNT) и может содержать не один SQL оператор, а несколько, которые порой затруднительно или даже невозможно соединить в один. Кроме того, я могу COMMITить отдельные SQL операторы внутри SP.
Если же рассматривать SP из одного SQL оператора (чтобы приблизить его к View), то естественно ни каких преимуществ (кроме см.ниже), одни накладные расходы на загрузку DLL.
Перед клиентским модулем (про сервер приложений ничего сказать не могу), SP на SQL (не на JAVA!) имеет на мой взгляд только одно существенное преимущество или фичу :) связанное с обходом прав доступа:

Может исполняться от имени создателя процедуры (например, от имени юзера с правами DBADM) ,что задается опцией DYNAMICRULES BIND при создании.

Таким образом, имея права на выполнение такой процедуры, можно не давая явных прав на UPDATE (DELETE, INSERT и даже SELECT) таблиц разрешить корректировать (читать) через процедуру отдельные поля или записи (удалять, вставлять). Или в сочетании с возможностью динамического построения SQL операторов выполнять любые запросы, которые не существуют в природе на момент написания приложения, и на которые, естественно, не могут быть розданы права заранее. Или выполнять запросы из заранее подготовленного списка (тексты запросов в поле пользовательской таблицы). Или, наконец, выполнять те же View, текст которых SP может вытащить из мемо-поля системных таблиц.
28 янв 03, 12:56    [116150]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
golsa
Member

Откуда: Красноярск
Сообщений: 789
В догонку.
SP бекапятся с БД. Поэтому при правильном проектировании (распределением бизнес-логики между клиентской частью и SP) нет проблем с версионностью. Т.е. один клиент может работать с любыми версиями структуры БД. Еще раз обращаю внимание: в SP можно реализовать алгоритмы выходящие за рамки одного SQL оператора (читай View).
29 янв 03, 07:28    [116743]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
uagg
Guest
Забавно, а народ ведь пришел к мнению, что в DB2 SP настолько неудобны, что лучше как угодно извратиться, лишь бы не использовать
30 янв 03, 14:37    [118197]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
NewYear
Member

Откуда: Большой адронный коллайдер
Сообщений: 2203
?
30 янв 03, 16:30    [118332]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
NewYear
Member

Откуда: Большой адронный коллайдер
Сообщений: 2203
просто у кого-то голова уже заточена под SP
30 янв 03, 16:35    [118344]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
Guest123
Guest
Если с применением или не применением TSQL ХП все более или менее понятно, то лично мне непонятно назначение extended ХП (какие только и присутствуют в DB2 и "сложно делаются" в MS и Sybase.). Лично мне не приходилось в своей практике писать такого рода процедуры. Кто что может сказать за них? Имеет ли смысл делать их на сервере БД? Может лучше их функционал, если он действительно нужен, выносить во внешнее приложение за пределы сервака?
31 янв 03, 18:36    [119452]     Ответить | Цитировать Сообщить модератору
 Re: Особенности DB2 - в чем цимус?  [new]
ggv
Member

Откуда:
Сообщений: 1810
Да спор бесполезный по поводу что лучше - SP или view... По мере надобности применять можно все. Если нужно. Кстати - зря так, что SP хреновые у DB2. Не хреновые они. Просто другие. Я их на С пишу. Дык по ходу дела SP может все, хоть за пивом сбегать :) Ну С он и в африке С :) В части... Ладно коротко - лазил по надобности в LDAP из SP.
A SQL у DB2 действительно очень силен, чувтсвуеться рука создателя :)
Кстати, как говорит сама дока, SP можно применять так же как вариант static SQL из dynamic приложения. Ну ясное дело, static SQL при наличии обновляемой статистики - песня, нет слов. Но иногда надо в dynamic SQL получить такое же. Есть два пути, один с ограничениями, не будем о нем, второй - SP. Гибкость, аднака.
Ну и само собой - fenced/unfenced - только отлизать SP надо, чтобы нехорошо не получилось. Производительность - песня :)
У меня сейча V8.1 workgroup на Solaris (Blade 100, 500 MHz single CPU кто не помнит) и на linux dual CPU 2.4 GHz Intel. Так вот моя задача (OLTP) шпарит по невыясненным причинам _гораздо_ шустрее на моем домашнем Blade чем на корпоративном сервере. Все одинаково, вплоть до сырцов приложения. Это к вопросу о стоимости линуксовой версии. за что платить-то ?
А так - читать надо, чтобы понять, но только с условием - читать во время реальной работы. ROLLUP, CUBE, GROUPING SETS - интересное чтиво. управление дисками/памятью...
Я так лично просто тащусь с возможности делать SP на С :) легко-просто-гибко называеться :) любой функционал доступен :)
Ну а если что-то реально тяжелое надо, как действителтьно работающие распределенно сревера - то по старому EEE, по новоми фиг знает как его - ES, что-ли, самое оно. правда, за хорошие деньги. НО ОНО ведь как работает!!! А как легко добольно таки настраиваеться ?? Я правда, с ним только игрался - задач таких нет... А жалко...
13 фев 03, 22:34    [128905]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2      [все]
Все форумы / IBM DB2, WebSphere, IMS, U2, etc Ответить