2 Дед Маздай

>Не перевирайте цитату.
>
>The SQL Server 2000 advantages:
># SQL Server 2000 is cheaper to buy than Oracle 9i Database.
># SQL Server 2000 holds the top TPC-C performance and price/performance results.
># SQL Server 2000 is generally accepted as easier to install, use and manage.
>
>The Oracle 9i Database advantages:
># Oracle 9i Database supports all known platforms, not only the Windows-based platforms.
># PL/SQL is more powerful language than T-SQL.
># More fine-tuning to the configuration can be done via start-up parameters.
>
>Таким образом, в оригинале мощнее не Oracle как сервер баз данных, а его язык >программирования в серверной части.

И тут его мысль сделала гениальный скачок. (c)

Каким это "таким образом"? Откуда такой вывод?
Да из этой статьи можно только сделать вывод, что автор статьи, а вместе с ним возможно и Дед Маздай, не разбирается в предмете или сознательно передергивет. Читаем сначала. Цену и оборудование пока пропускаем, дальше идет "T-SQL vs PL/SQL". Поддержка B-tree индексов отнесена к свойствам T-sql. Таким образом поддержка ораклом 5 типов индексов (против одного у MSSQL по статье, но на самом деле двух, автор статьи наверное просто не знает) перекочевала из свойств сервера в свойства языка. И защитники MSSQL стыдливо признали, что да, T-SQL слегка уступает. Но проблема в том, что B-tree индексы, как впрочем и всякие другие есть не свойство языка, а свойство SQL-сервера. Так вот это не язык проигрывает по данному пункту, а сервер. Это же относится и к триггерам before incert и объектным таблицам: это не проблема языка, а проблема сервера. Имеем: из 5 пунктов по языку 3 отнесены к нему неправильно и следовательно не попали в сравнение собственно SQL серверов. По случайности это как раз те пункты, по которым MSSQL безусловно проигрывает (а индексы - вообще ключевой параметр).

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

Читаем дальше. Действительно, с длинными именами таблиц, сохраненок и пр. ораклу не повезло, придется ограничиться 30 символами. Что такое index length не могу понять, пробел в образовании, объясните кто может. А вот дальше опять начинаются интересные вещи.
max char() size: MSSQL - 8000, ORACLE - 2000;
max varchar() size MSSQL - 8000 ORACLE - 4000.
Это серьезно. А как же длинные документы хранить в оракле? А в CLOB-ах: You can apply character functions to CLOBs as if they were VARCHAR2 data. А в CLOB влазит по-моему до 4GB на винде. Автор статьи скромно умалчивает об этом. На всякий случай сообщаю: у оракла вообще нет (в oracle 8i точно не было) типа varchar, а есть varchar2.

Идем дальше.
constant string size in SELECT: MSSQL - 16777207, ORACLE - 4000;
constant string size in WHERE: MSSQL - 8000, ORACLE - 4000.

Явное преимущество MSSQL-я. Правда не понятно, что такое в данном контексте "constant string", может если сравнить "variable string size", то оракл выиграет, ну да ладно. Пусть знатоки оракла скажут за оракл, а я скажу за MSSQL: автор статьи нас за лохов держит. Хорошо известно, что MSSQL 7.x имел ограничение 256 таблиц в запросе. Это тяжелое наследие досталось ему от версии 6, которая имела ограничение 16 таблиц в запросе, включая копии. Даже написание седьмой версии практически с нуля (согласно деду Маздаю) не позволило мелкософтовским програмерам избавиться от этого ограничения, а только отодвинуть подальше. Звучит странно, но речь не о том. MSSQL2000 наверняка страдает наследственными болезнями. Поправьте меня, если я ошибаюсь. Пусть, этот лимит отодвинут, например, до 1024. Тогда на каждую из 1024 таблиц в запросе приходится 16777207/1024 байт, что составляет примерно 16383 байта на таблицу. Хотел бы я посмотреть на 16Кб запрос в котором всего одна таблица, даже килобайтный запрос с одной таблицей не представляю. Т.е. такая длина запроса просто смысла не имеет даже формально: мы раньше упремся в другое ограничение, о котором автор статьи тоже почему-то не вспоминает.

Но есть еще проблемка. По признанию автора статьи SQL диалект оракла мощнее такового в MSSQL-е. Следовательно запросы для оракла часто могут быть записаны либо более компакно либо вообще аналогов в T-SQL-е не имеют. Так чего стоит сравнение максимальной длины запроса в байтах, если на T-SQL-е его возможно вообще в чистом виде не запишешь, только через процедуры?

Все что осталось - цена и требования к оборудованию. Насчет оборудования - сильные у меня сомнения, но возможно автор прав. Хотя 8i требовал где-то вдвое меньше ресурсов, неужели девятка настолько тяжелее? А цена - да, MSSQL дешевле.

Эту статью вообще несерьезно приводить в качестве аргумента. Сомневающимся советую еще прочитать первую, та вообще больше на шутку похожа.

2 AISOFT

>Зато выясняется, что MS посоветовал изменить структуру запроса, так это MS SQL SERVER плохой...

Говоришь неправду.

2 Chkalofff

>Это полный бред, если считать, что ограничение на 17 вложенность является определяющей. В реальных условиях на планете Земля, если упирается в это, то это проблема в проектировании структуры БД.

А я и не говорил, что это условие определяющее. Но приятного тоже мало. На самом деле цифра оказалась вполне реальной - 4. У мелеософта всегда так: по документации держит 256, но больше 10 заводить не рекомендуется, не заработает. Это низкий класс.

>Вопрос стоит о реальной задаче. Назовите реальную задачу масштаба предприятия, с которой не справится MSSQL, но справится Oracle.

Вопрос так не стоит (не стоял). Речь шла о задаче вообще. Я сформулировал задачу (точнее ограничил множество задач). Я не утверждал, что ее нельзя решить другими методами. Но на сях тоже можно все написать. Зачем эти SQL сервера повыдумывали?

Но если так хочется можно переформулировать: любая задача, решаемая ораклом и для решения которой необходимо построение запроса с 17 уровней вложенности представлений на MSSQ2000 не решается никак. Я не утверждаю, что задача существует. Это теоретический спор, к реальности отношения мало.

>Что касается вставки n записей, что тут конечно может быть много причин, но возможно на других базах вы заранее аллокировали пространство для этого, а на MSSQL сделали базу размером 1mb по умолчанию. В процессе вставки системе пришлось постоянно ресайзить базу и лог. Хотя причин еще может быть туча. В любом случае, то что вы скрываете код этого теста от общественности, делая такими заявления, выгладить не очень убедительно.

n записей мало, пусть будет m записей.
А что, по коду можно будет выяснить как база лог ресайзила? А потом появится законный вопрос об оборудовании и о настройках. Все настройки я и не знал никогда, как по умолчанию сервера встали, так и работали. Дело было на NT, ее нет под рукой, на вынь2K MSSQL7 наверное по-другому встанет.

Я не нашел скриптов, дело было 4 года назад. Скрипты простые, я могу попытаться повторить когда будет время, мне и самому интересно. Я повторял тест 2 раза в разное время с тем же результатом.

Еще раз о первоначальном предмете спора. Речь шла о том, что MSSQL прощает ошибки разработчиков и админов, а оракл нет. Я сказал, что это не так и в качестве контрпримера привел тот тест. С ораклом я разобрался, а с MSSQL-ем нет. В обоих случаях и читал документацию, менял настройки. Руки кривые? Но тогда получается что оракл проще, раз я кривыми руками его исправил, а MSSQL нет. А если руки прямые, то MSSQL кривой, раз прямыми руками его нельзя заставить нормально работать. Последний вариант - что я все выдумал.

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