krids wrote:zVlad wrote: Опыта работы на МФ? Опишите мне его, пожалуйста, в общих чертах. Где, кем и с чем Вы работали.
Нет. Вы неправильно поняли. Имелся ввиду опыт работы с SAP.
Хотя опыт работы с МФ в прошлом имелся (5 лет DB2/zOS application DBA, раз уж Вам так любопытно)
zVlad wrote: Обоснуйте, раскройте, Ваше заявление о 10%, тогда и посмотрим кто понимает о чем речь а кто не совсем.
Я прекрасно знаю как разрабатывают эффективные и производительные приложения для DB2/zOS (и сам в этом учавствовал) и, глядя каждый день на то, каким образом с базой данных (DB2/AIX) работает SAP, идея о размещении SAP Database Instance на DB2/zOS c точки зрения производительности и цены этой производительности лично для меня является весьма и весьма сомнительной.
Эмпирические 10% выведены из анализа особенностей структуры БД SAP, логики работы ABAP-программ, development-фичей СУБД, которые оно использует и опыта разборок с неэффективным SQL-кодом, который оно генерирует. Возможно кто-то сочтет этот процент более высоким, на мой взгляд он не более такового.
У меня тоже есть пяток лет работы DB2 DBA (просто DBA, не application). Есть у меня и ИБМ лайсэнс по DB2 (это не типично для МФ специалистов, но я потратил время и прошел тестирование).
Про 10% Вами было сказано в следующем контексте:
Вот-вот. Именно поэтому под БД SAP'а покупать СУБД, которая вместе с платформой стоит бешеных денег затем, чтобы неиспользовать и 10% её возможностей - это, имхо, бред.
Использование возможностей конечно зависит от дизайна приложения и требований к нему. Наше приложение, например, написано в прицеле и на DB2 и на Oracle и поэтому требованием было исплользование минимально особенностей обеих баз данных. По этому в нашем приложении нет ни первичных/вторичных ключей, ни триггеров/сторпроцедур (недавно скромно появились), ни многого другого. (Однако это не мешало наличию весьма своеобразных предикатов и неуместных коррелированных сабкуэри). Тем не менее наше приложение использует статический SQL (о чем собственно и говорилось в моем сообщении в реакции на которое Вы заявили о 10%). Тем не менее сказанное мною о динамическом SQL в DB2 вовсе не означало констатации недоиспользования возможностей DB2. Оба, динамический и статический SQL, совершенно нормальны в DB2. Здесь можно лишь говорить о разной производительности, да и то не всегда.
Ваша же фраза (см. здесь же выше) имеет совсем другой посыл и намекает на неразумную трату в приобретении DB2 для например SAP. А это уже совсем другой вопрос и ему нужно дать правильное обоснование. То что дизайн приложения для реляционной БД задал ограниченные потребности функциональности вовсе не означает что, например, оптимизатор DB2 лишь на 10% такой дизайн удовлетворяет. Нет оптимизатор выполняет все 100% того что может быть сделано для заданного дизайна. То же самое с механизмом блокировок, пулами, утилитами, секьюрити, бэкап/рестор и т.д. и т.п.. А что в случае с Оракл дела обстоят как то иначе?
Вот и у Вас кстати проскальзывает что на самом деле Вы говорите не о возможностях, а о производительности:
Я прекрасно знаю как разрабатывают эффективные и производительные приложения для DB2/zOS (и сам в этом учавствовал) и, глядя каждый день на то, каким образом с базой данных (DB2/AIX) работает SAP, идея о размещении SAP Database Instance на DB2/zOS c точки зрения производительности и цены этой производительности лично для меня является весьма и весьма сомнительной.
Сомнения хорошо бы хотя бы иллюстрировать примерами, а лучше дать теоритическое обоснование. Надеюсь Вы это понимаете? Ну а пока Вы готовите примеры и теоритические обоснования я расскажу свое мнение об этом.
Разработка DB2 для LUW началась много позже чем DB2 для z/OS. Разработчики DB2 для LUW сначала изучили внимательно DB2 для z/OS (я об этом знаю от одного из руководителей разработки DB2 для LUW), и их целью было максимально ипользовать подходы DB2 для z/OS. Разумеется стопроцентного совдания нет и не могло быть, но говоря в общем эти две БД во многом одинаковы. Так что Ваши сомнения о "о размещении SAP Database Instance на DB2/zOS c точки зрения производительности" как бы не очень убедительны с точки зрения теории.
Более того, если говорить о производительности как таковой, то еще дедушка Дэйт писал в 70-х для таких как Вы что производительность реляционных БД мало зависит от дизайна и может изменять путем оптимизации выполнения запросов в очень широких пределах, а также то что " ...двумя основными характеристиками производительности являются число операций ввода-вывода и продолжительность обработки (объем работы центрального процессора)." Первое зависит от физического дизайна БД, а второе во многом от оптимизатора, который у DB2 для z/OS на сегодня более продвинутый чем у какой-либо другой RDBMS. Алаверды, как говорится.
