В кратце могу перечислить с чем ты столкнёшься как разработчик FB (про оракл не знаю):

Отрицательное:

1) Ближайшее нечто похожее на IBExpert - это EMS. Жалкое зрелище.
2) Отсутствие триггеров FOR EACH ROW, триггеров BEFORE
3) Фактическое отсутствие альтернативы циклу FOR SELECT (курсоры очень тормозят, даже однонаправленные, сама конструкция курсоров очень громоздкая и неудобная)
4) Отсутствие последовательностей/генераторов (после них мне автоинкремент показался каким-то не таким)
5) Если наступишь на баг, то будешь ждать годы. Никто для тебя специально не будет собирать билд с фиксом бага как это запрсто может быть в FB.
6) Убогий язык TSQL
7) Убогий аналог селективных процедур

Из положительного:

1) Более стабильный сервер чем FB
2) Хороший оптимизатор
3) Динамические ссылки на курсор
4) Дополнительные типы данных (BIT, SQLVariant)
5) Более быстрый протокол
6) Можно переименовываать таблицы
7) Гетерогенные запросы

Из того что я не знаю как оценить:

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


В итоге лично мне с ним было вкрай тяжело работать. Мы поставили перед клиентом устовие: или переходим на FB, или ищи других программистов, потому что продуктивность у нас снизилась, мы постоянно нервнияали, ругались, вспоминали Билла. Он согласился. Другими словами если клиент очень выгодный и другого варианта нету, то можно работать.

2 pkarklin

У меня после того было опыта общения с ним вплоть до марта этого года. Вполне достаточно чтобы иметь о нём общее представление.

По поводу того что я не умею его готовить. Так а я и не отрицаю.

По поводу объективности. А что я не так сказал? Я изложил человеку видение с точки зрения того кто таньше работал на FB. В говно я его сильно не сажал, кучу достоинств привёл, которые смог вспомнить.

Заключение - моё личное мнение. Мне с ним вкрай тяжело было и неинтересно. Ну что я могу поделать с этим? Наврать что-ли, сказать что мне понравилось? Ну не нравится он мне, злой я на него чего и не скрываю :-)

2 pkarklin:

Я бы мог привести скрипты, но на это время нужно потратить, а в результате это будет бесполезно.
Давайте это всё повернём следующим образом: я утвреждаю что имея долгий опыт работы с FB работать c MS SQL будет очень непривычно и местами сложно и хочу предупредить автора топика что в MS SQL всё совсем не так как в FB и наверное в оракле.

2 pkarklin:

Я думаю можно без тестов. Мне надо было написать функцию, которая по древовидной структуре делала довольно сложные вычисления со всякими промежуточными итогами. Это можно представить примерно так:


То есть мне надо было иметь несколько вложенных курсоров. И такая канструкция - это просто смерть для MS SQL

С другой стороны в FB я бы написал:

и эти вложенные FOR SELECT будут летать почти с такой же скоростью как обычный JOIN.

Думаю что вы и без примера знаете что в MS SQL такая конструкция умрёт на паре тыщ листьев в дереве. Причём, что интересно, я перепробовал с десяток вариантов параметров у курсоров и FORWARD_ONLY (или как там его, забыл уже названия) показал себя даже несколько хуже чем двунаправленный курсор.

2 pkarklin

Да у меня там запросы элементарные типа получить сумму где поле равно занчение ключа. Индексы все были. Собственно на оптимизатор и скорость выполнения запросов никаких проблем.

По поводу CTE - знаю такое. По поводу раскрытия дерева циклом без курсора - не знаю. Правда это не решило бы проблему, но всё же интересно как это сделать (дерево представлено ссылкой в таблице на саму себя). Вроде ж CONNECT BY и подобного небыло в MS SQL 2000...

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

2 SergSuper

Да вот в том то и дело что у меня в дереве не несколько тысяч, а несколько сотен элементов было. Процедура считала деньги по ресурсам, привязанным к элементам этого дерева, причём сразу в нескольких разрезах. И торомоза тут именно в курсорах, потому что больше там торомзить было НЕЧЕМУ. А в FB циклы FOR SELECT и курсоры работают очень быстро и ними все пользуются и мораль всей этой повести в том что человек прийдя с FB очень сильно обломается в этом месте и ещё парочке других мест, о которых я писал выше.

Это мой ответ вопрошавшему на вопрос: хотелось бу узнать технические моменты.


PS Вобще у нас в профессии странные тенденции. Странно ведь будет если гениколог полезет со своими знаниями в попу по проктологической части, хоть органы и рядом находятся.
А у нас же в программировании почему-то нормальным считается сегодня пописать на одном, завтра на другом, послезавтра на третьем, в результате досконально не знать ничего.
Так и в этом случае. Писали писали на оракле, а тут бац - MS SQL пожаловал. Стали под него писать. И в результате получается как в известном ролике "если бы программисты строили самолёты".