авторНу, основной продукт фирмы на базе его сервака работает. SQL не справился (сложные связи/реал-тайм обработка сложных запросов/нереляционные структуры плюс полный контрол над кодом).
Подтверждаю, мог и не справиться. Я вот насмотрелся/натерпелся/очумелся/... на разные проекты под MSSQL и пришел к забавному выводу - у MSSQL есть страшный грех: он абсолютно не переваривает кривое программирование. Мне иногда такие "чудеса" показывали, которые он вытворял, что я сначала глаза начинал протирать и вспоминать, почему же это у меня такого никогда не случалось. А потом я видел реализацию этой "супер-БД" и у меня волосы дыбом на голове вставали, я опять начинал жалеть, что снова взялся за старое, опять согласился выступить в качестве эксперта по MSSQL и мне опять подсунули чудо-юдо (хотя с другой стороны если так подумать, с чего бы это меня приглашали на консультирование, если бы в БД был порядок).

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

авторМогу привести пример кривой оборотно-сальдовой ведомомти, построенной на прочти нормальной структуре, где MSSQL все еще работает, а ASA прощается разными способами (в зависимоти от операционки), но стабильно.
Есть одно большое НО. Каждый раз, когда у меня ASA прощается из за каких то глюков, я вылававливаю, на чем он спотыкается, далее просто захожу на Sybase.com, регистрирую баг, отвечаю на вопросы службы поддержки, если им что то не понятно и через некоторое время скачиваю патч (от месяца до пару в зависимости от загрузки отдела инженерного сопровождения), в котором со мной больше ASA не прощается :) Печально, но MSSQL этим похвастаться не может, многие баги в нем могут тянуться через большое кол-во сервис-паков, несмотря на то, что уже заявлены и описаны. Так же до кучи я спокойно могу зайти на форум по ASA, посвященный его дальнейшему развитию и пообщаться (поспорить) с разработчиками по поводу доработки его функциональности, которая бы очень пригодилась. Наглядный пример такого форума - это появившиеся в ASA 9 Common Table Expression, Web-сервисы, возможность выборки из ХП и т.д. Недавно выпущенный апгрейт ASA до 9.01 опять же демонстирует кучу новых возможностей, ноги которых растут из данного форума, что не должно не радовать разработчиков.

Cat2
Да в принципе все, что можно найти в советах "Не делайте так" форума MSSQL присутствовало в последнем проекте, который я правил:
- постоянное использование по любому чиху темповых таблиц, к тому же получаемых посредством запроса SELECT INTO #TempTable
- полное отрицание подзапросов, вместо них всегда использование темповых таблиц
- частое использование UDF и ХП в качестве "повторно используемого кода", их в БД не одна тысяча, друг друга вызывают этак уровнем вложенности до 20, ну прямо продуманная иерархия обьектов, ляпота
- никаких поддержек транзакций, все прет в AUTOCOMMIT, соотвествующе постоянные DELETE перед любым шагом - а как же, вдруг посреди пути процедуру вышибло и только половину таблиц она изменить успела
- гордый отказ от использования курсоров - мы же крутые разработчики, никаких курсоров, циклы WHERE EXISTS() ... гораздо веселее
- никаких попыток разруливать блокировки, знай себе по умолчанию PAGELOCK долбит, еще и постоянные таблицы в качестве временных используются, и что странно - вроде все данные по @@SPID разделены, а вот пользователи почему то друг друга блокируют
- триггер друг человека, поэтому его обязательно и везде надо использовать. Только в MSSQL его как то "криво" сделали - возвращает понимаешь весь набор изменяемых записей, не удобно обрабатывать, вызывая на каждую запись ХП (а как же иначе, ведь ХП повторно используемый код, все по правилам), глядишь еще и этот ужасный как говорят курсор организовывать придеться. Выход всегда есть - правильно, IF (SELECT Count(*) FROM Inserted) > 1 RAISERROR('Нельзя добавить больше одной записи', 16, 1) . Шик, нигде злобная клиентская часть не добавит больше одной записи, соблюдается понимаешь главный принцип - контроль (правда в данном случае не целостности, а контроль, чтобы решение не навернулось). Помниться мне еще Glory как то удивлялся, зачем запрещать в триггере изменять больше одной записи.
- План запросов это все от лукавого. Ведь и так понятно, что как бы программист не написал запрос, умный и добрый MSSQL всегда его наиболее оптимально выполнит, подумаешь там всякие NOT EXISTS, соединение таблиц через OR, использование UDF в WHERE, которые ко всему прочему частенько служат для соединения таблиц, круто же в UDF по переданному параметру найти и вернуть ID, очень понимаешь потом в запросах удобно использовать на другие таблицы ее.
- Кстати, никто не подскажет - а что такое статистика, размер страницы БД, FILL FACTOR таблиц, и почему везде на многомилионных таблицах кластерный индекс тормозит на операциях удаления и добавления данных, ведь говорили же, что на нем всегда все быстрее. наверное это все злые термины, голову понимаешь пудряд почем зазря
- Странно, почему, как только поменяли сервер на многопроцессорный и мощный, все так стало тормозить - наверное надо один процессор ОС отдать, другой MSSQL

Ну и так далее и тому подобное. Я вообще когда эту базу рассматривал, как одну из возможностей видел убить всю ее логику, оставить только входящую структуру и переписать все оставшееся с нуля. К сожалению это не удалось - проектировка БД тоже на уровне - после того, как я вывел схему в PowerDesigner, то первой моей мыслью было - надо же, PD то оказывается глюкавит с отрисовкой диаграмм, вон как размазал линиями, покрыв почти всю диаграмму. Однако сделав zoom я с ужасом понял, что это не PD глюкавит, на таблице, к которой на глазок шло больше всего связей я насчитал порядка 56-и FOREIGN KEY. Далее уж по ходу пьесы я нашел кучу структур в виде деревьев, для которых были написаны UDF, которые в виде рекурсии генеририли путь от node до вершины, а на их основе были созданы COMPUTED поля - удобно черт подери - а то там еще о каких то алгоритмах говорят, рекурсивные запросы в СУБД встраивают. Далее я нашел таблицу, у которой было 12 индексов на одни и те же поля. Уж потом вскрылась куча таблиц, у которых частенько дублировались FOREIGN KEY. В запросах на не хилые по обьему таблицы я нашел уже потом "веселые связи", типа:
SELECT T1_ID = t1.ID, T2_Name = t2.Name
FROM Table1 t1, Table2 t2, Table3 t3, Table1 t4
WHERE t1.ID = t2.ID AND t2.ID = t3.ID AND t3.ID = t4.ID AND t4.ID = t1.ID
В принципе этот запрос MSSQL разрулит, но там ситуации были помощнее. Кстати я не зря привел пример в ANSI 89, все скрипты писались в таком же духе, когда в ХП нет отступов слева и между, когда идет непрерывный потом операторов SELECT, DELETE, INSERT, плюс в SELECT-ах в FROM до 30 таблиц и все связи в WHERE, выглядит просто впечатляюще.

В общем начальство меня просило вынести ведикт, я его вынес - пока деньги приносит, пусть себе работает и окупается, править там нечего. Жить проект будет настоящим, будующего у него нет.

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

Лично я чем дольше программирую, тем больше убеждаюсь, что практика делания своих велосипедов не надежна и наносит больше вреда, чем пользы. С точки зрения эффективности проектирования задача должна быть четко поставлена и разграничена - если пишется прикладной софт, то он должен писаться на существующих средствах разработки для такого софта. Если пишется сама среда разработки, то это отдельный продукт, ориентированный на определенный рынок. Соотвествующе для каждого направления выгодные разные средства разработки ПО, у каждого своя стоимость и маркетинговая политика развития, ну и т.д. Писать же только для самого себя инструмент, на котором потом делать и продавать прикладное ПО, мне кажется занятие не благодарное и является просто потерей времени. Я уже молчу про то, что собственный инструмент разработки, не продвигающийся на рынке как отдельный продукт является закрытой системой, требуется процесс обучения новых сотрудников, не являясь окупаемым и тиражируемым он по любому будет иметь большие ограничения по функциональности, доработка и его сопровождение потребует необоснованных вложений средств и времени, так же молчу про размер и качество документации на такой инструмент и зависимость всего прикладного ПО от разработчиков движка - вот уйдет шеф mv куда нибудь, то то весело станет. В общем лично мое мнение, что движки писать можно и нужно, но только при условии, что они позиционируются как отдельный тиражируемый продукт, могут занять свою нишу в рынке продуктов ПО и приносить доход. Иначе овчинка выделки не стоит - гораздо проще и эффетивнее правильно выбрать для написания прикладного ПО наиболее подходящий из существующих продуктов, чем лепить свое. Пока во всех случаях рассмотрения различных велосипедов - хороших, плохих и даже гениальных я приходил только к одному выводу - их разработчики просто ничего не знали, что уже существует ПО, делающее все то, что им нужно, а движки лепили на тех самых инструментах, на которых привыкли программировать и которые не умели все то, что им было нужно.

Конечно все вышесказанное мое личное мнение, навеяное опытом работы с чужими и созданием собственных движков, компонент и библиотек, а может быть я уже просто перестаю быть программистом, раз пишу такие вот возмутительные рассуждения вслух :)

авторизвините конечно, но что такого сделал билл? я про программирование говорю, а не про маркетинг
Вроде как ходили слухи, что Билли написал ДОС. Или это только слухи ? :)

автортем не менее компания SONY даже строчки кода не берет со стороны.
начиная от драйверов и кончая играми
Я честно говоря про Sony ничего не знаю, но очень сильно сомневаюсь, что все драйвера и даже игры пишутся у них на собственном языке, собственном компиляторе, собственной IDE, только собственных библиотеках и разработках и т.д. Если это так на самом деле, то я буду крайне удивлен - наверное тогда богатая это компания Sony, раз может позволить себе содержать такой штат людей, работа которых не приносит прямого дохода компании и служит только для обеспечения ПО самой себе. Ну а то, что они в конечном ПО используют свои наработки, так это правильно - крупный поставщик решений не имеет права хоть как то дискредитировать себя, получив на свою голову кучу проблем в виде чужих багов или судебных исков по поводу чужих, как потом оказывается запатентованных уже кем то строчек в коде :)