Как раз в тему по данному топику сегодня одному ораклисту удачно высказался один из разработчиков команды ASA на их официальном форуме:
авторIf you *want* big, fast and expensive, go with Oracle or DB2. If you
want small, fast, friendly and affordable, go with ASA 9. It's your
call, some folks *like* to spend money :)
Полностью с этим высказыванием согласен - нечего ту же ASA пытаться запихнуть на задачу с огромными обьемами данных и большим кол-вом подключений. Так же нечего делать на Оракле задачи, которые должны работать в удаленных филиалах автономно (без какого либо администрирования) с какой то сотней гигабайт и 70-100 активных сессий. Легче в центре поставить Оракл, по удаленным филиалам ту же ASA, и через ее механизм репликаций спокойно обмениваться информацией, хоть в онлайне, хоть в оффлайне. Благо на текущий момент ASA 9.0.1 по реализации ANSI SQL и расширениям ничем не уступает тому же Ораклу или DB2, разная только архитектура СУБД, что и правильно с точки зрения круга применяемых задач (насколько я знаю, последнее оставшееся известное мне отличие ASA WatcomSQL от PLSQL - это (Field1, Field2) IN (SELECT Field1, Field2 ...) - будет реализовано этим летом в 9.0.2).

То же касается и MSSQL - эта СУБД имеет свою архитектуру и свой круг задач, хотя хочу заметить, что в данном случае команда iAnywhere поступила мудрее, не соперничая с другими СУБД, а заняв свою нишу задач мелкого и среднего бизнеса и сделав возможность полноценной работы с другими СУБД через прокси-таблицы и гетерогенную репликацию. Судя по форумам ASA такая политика там приносит свои плоды - выгоднее разбить проект на 3 части - центральный (Оракл), удаленный (ASA9) и мобильный (ASA9 UltraLite), съэкономить денюшку (сервер ASA9 - 400$, лицензия 100$, на процессор 2500$) и не чесать репу - а как это запустить проект на Оракле в филиале Магадана, где не то что сисадминов, но и интернета то нету, или как всем мобильным сотрудникам поставить СУБД на КПК PocketPC/Palm с репликацией на центральный сервер :) IMHO все что касается любых удаленных или автономно работающих промышленных СУБД здесь у ASA конкурентов нет.

И кстати ограниченность MSSQL по сравнению с другими СУБД имеет свои явные плюсы - в конце концов люди хоть учаться правильно проектировать БД и писать запросы. IMHO вседозволенность хороша только специалистам с большим стажем, которые четко знают, что можно, а где лучше остановиться. Иначе получается такое ... что волосы дыбом встают. Я вот до сих пор на форуме Sybase борюсь с "курсорниками", которые пытаются в обязку сделать UDF, в нее запихнуть курсор и вызывать эту UDF из запросов. Считаю это явным антирелляционным подходом и полным пренебрежением наличия отличного самообучающегося оптимизатора. Кстати забавно, но большинство "курсорников" почему то оракляне. Я вот все никак не могу понять - то ли мне не везло на разработчиков Оракла, то ли на Оракле с помощью курсоров, в отличие от MSSQL, ASE, ASA можно действительно быстро и эффективно перелопачивать данные, хотя все равно возникает вопрос - а разве по любому план запроса, сделанный оптимизатором не будет эффективнее ?

авторВстроенный оптимизатор (план выполнения), желает желать лучшего
...
Если запрос сложен, приходится последовательно строить несколько вьюверов.
Ой, что то я сомневаюсь, что у MSSQL так плох оптимизатор запроса, раз Вы любите вьюверы строить на сложные запросы. Вот думаю народ, работающий на любой СУБД не даст мне соврать: увлекательство представлениями - это прямой путь к тормозам. Плюс на личном опыте могу сказать, что как минимум у MSSQL и Sybase ASA при соединении в плане запросов основного запроса и вьювера в некоторых ситуациях (чаще LEFT JOIN) может привести к тому, что оптимизатор проведет не то соединение, которое ожидалось и результат выполнения просто вьювера и использование его в запросе будет отличаться.

Так что лучше при написании сложных запросов не забывать о временных таблицах, которые позволяют разбить на несколько этапов сложный план запроса и упрощают жизнь с блокировками. Жалко только, что в MSSQL до сих пор нет NOT TRANSACTIONAL времянок, на примере ASA могу сказать, что они дают неплохой выигрыш в скорости. Так же бы не помешали GLOBAL TEMPORARY TABLE, описание которых хранится в БД и они автоматом создаются для каждой стартующей сессии в своем контексте данных (на них даже триггеры вешать можно).

IMHO с точки зрения проектировщика: MSSQL хороший сервер, но по возможностям ему явно не хватает функциональности для реализации всей логики на сервере. Например в ASA я имею глобальные сессионные переменные, возможность реагировать и выполнять свой код на различные события, в т.ч. на подключение и отключение сессии. Как результат - БД на ASA у меня действительно полностью автономна - не нужно с клиента чего то создавать или запускать ХП, при подключении сессии все что нужно инициализируется сразу. Такие возможности позволяет в дополнение контролировать подключение и например отказывать в доступе по IP или имени приложения. Или же при реализации собственных блокировок автоматически удалять их с таблиц при отсоединении сессии.

andbaryА пока... у меня 7 сущностей (должна быть 1) и каждая состоит из 10 связанных таблиц... и я объеденяю все в одном запросе...
В Оракле можно вручную указать порядок выполнения... а оптимизатор MS на такое (количество связей) просто не расчитан...
Если рассуждать чисто филосовски, то одна медаль имеет 2 стороны. На одной стороне достоинство Оракла в полном доступном тюнинге СУБД, позволяющего работать даже с кривыми решениями и как следствие недостаток других СУБД, не имеющих таких возможностей. На другой стороне медали с точностью наоборот - явные, открытые для пользователей настройки СУБД не стимулируют разработчиков Оракла к усовершенствованиям в области движка СУБД и и его пользователей к написанию более кач-венных решений. А зачем ? - если оно и так работать будет. В том же MSSQL ситуация получается благополучной - его "ограничения" с одной стороны развязывают руки MS, которая может более спокойно совершенствовать свой движок СУБД, так как он не завязан на "тонкие настройки" сисадминов, а значит не имеет жесткой зависимости от них.

Из всего вышесказанного я делаю вывод: Ваш пример не годиться, так как могу со всей уверенностью заявить, что на MSSQL никто бы просто не додумался так спроектировать БД (она бы просто не работала), а значит у Вас не встал бы вопрос насчет такого кол-ва таблиц в запросе, будь это решение не на Оракле.

P.S. Кстати на недавно проходившей конференции по OLAP серваку Sybase IQ, приезжавший специалист по нему как раз рассказывал и демонстировал решения, переведенные с других СУБД и обьяснял причины. С переводами с MSSQL было все понятно - блокировочник, да и все таки движок не рассчитан на обработку террабайтов информации, а вот с Ораклом было интереснее. Именно на нем частой мотивацией перевода аналитической БД на платформу IQ было кривизна решения. Например, нам продемонстировали схемку, где у одной таблички было пятьсот с чем то полей. Естественно когда БД стала большая, то тут и Оракл стал заваливаться на бок, хотя народ пытался все это дело разрулить разными дикими способами, вплоть до разделения таблицы на целую группу таблиц (на Sybase IQ потом перенесли первоначальную схему, ему в принципе все равно, сколько полей в таблице). Я лично из всего увиденного на конференции и сказано сделал для себя в общем то известной для всех в бытовой жизни вывод - "2 в одном" всегда хуже, чем по раздельности. Лучше уж иметь в проекте чистые OLTP-блокировочники, не требующие администрирования и имеющие более менее граммотные оптимизаторы, плюс для консолидированной БД чистый аналитический или OLAP сервер, вполне возможно версионник, для того, чтобы не иметь проблем с закачкой данных (как тот же Sybase IQ), но специально оптимизированный под хранение и обработку больших массивов информации. Оракл же получается вроде как два в одном: OLTP + OLAP. Соотвествующе это требует больших накладных расходов на него и сужения круга применения. Это конечно мое личное мнение, но согласитесь самолеты-амфибии и по воздуху хуже летают и по воде не так быстро плавают. Наверное что то в этом есть :)