comparatorСкажите, а не попадалось ли кому-нибудь в сети сравнение СУБД MS SQL Server и Oracle с точки зрения разработчика серверной части приложений (PL/SQL и T-SQL Developer'ов). Я накопал достаточно много документов, сравнивающих две этих СУБД в части стоимостей владения, администрирования, сопровождения, обеспечения отказоустойчивости и масштабирования.
Хотелось бы сравнить возможности и продуктивность работы разработчиков.

Часть найденных мною ссылок публикую здесь, может кому понадобятся:


http://www.oracle.com/technetwork/products/clustering/overview/twp-racsqlserver-2008-130739.pdf

http://voices.yahoo.com/oracle-vs-microsoft-sql-server-why-oracle-preferred-6893930.html

http://www.dba-oracle.com/oracle_tips_oracle_v_sql_server.htm

http://alinean.com/PDFs/Alinean-MicrosoftAndOracleTCAStudy.pdf

http://www.oracle.com/us/products/database/039433.pdf

http://www.dba-oracle.com/oracle_tips_oracle_v_sql_server.htm

старая песня, уже давно партиции есть. Непонятен практический толк от разных размеров страницы и наличия битовых карт в индексах Оракла. Также Оракл сам уже предлагает автоматическую подстройку памяти.

comparatorInfernal V. RavenНу и занахрена тогда спрашивать чем одна СУБД лучше? Поставьте вопрос корректней - помогите обосновать выбор Oracle при сравнении Oracle и MS SQL.

А кто вообще-то спрашивал, какая СУБД лучше? Я точно не спрашивал. Просить обосновывать выбор СУБД Oracle при сравнении Oracle и MS SQL мне тоже нет никакой нужды, я нашел достаточно материалов, сравнивающих две этих СУБД в части стоимостей владения, администрирования, сопровождения, обеспечения отказоустойчивости и масштабирования и могу сделать эту работу сам.
Читаем первый пост: Хотелось бы сравнить возможности и продуктивность работы разработчиков.

Типа: есть аналитические функции/нет аналитических функций, есть битмап индексы/нет битмап индексов, есть реверсивные индексы/нет реверсивных индексов, есть пакеты/нет пакетов, есть дополнительные опции типа Spatial, Text, Intermedia/нет их, есть материализованные представления и ROLLAP, MERGE, MODEL, DIMENSION, CUBE, function-based indexes, есть ли возможности автоматизированного тестирования (пусть и третьих фирм) ну и так далее.
Конечно я виноват, что не представил вам критерии сравнения, но я надеялся, что у кого-нибудь уже найдется готовый материал, содержащий эти критерии.

Хотелось бы услышать о продуктивности для разработчика наличие битмап индексов, например. Продуктивность - это количество работы (в данном случае разработка кода) в час. Так вот объясните мне корреляцию между наличием/отсутствием битмапного индекса на продуктивность.

softwarerOYMХотелось бы услышать о продуктивности для разработчика наличие битмап индексов, например. Продуктивность - это количество работы (в данном случае разработка кода) в час.


По этому определению для максимальной продуктивности не нужны никакие фичи и вообще СУБД не нужна, а нужен только текстовый редактор, приспособленный к максимально быстрому набору кода методом "копи-паст".

Продуктивность - это мера способности быстро решать актуальные задачи. Там, где один разработчик выполнит уйму работы, написав, скажем, пять тысяч строк кода в день, другой напишет сто строк за час - и окажется более продуктивен. Битмап индексы позволяют эффективно решать некоторые задачи (а сделай-ка мне отчётик, чтобы можно было настраивать выборку по некоторым из вот этих показателей и чтоб летало), которые без них решаются плохо и долго либо удовлетворительно не решаются вообще, и этим при уместном применении они весьма поднимают "продуктивность для разработчика".

Все же хотелось от Вас получить конкретный пример. Например есть таблица на 5 млн. строк, есть поле, которое может принимать 30 возможных значений. Создадим битмапный индекс для этого поля в Оракле. Создадим B-tree индекс в SQL Server.
И вот здесь напишите мне какого рода отчеты нужно разработать, чтобы "ораклист" потратил 1 час, написав 100 строчек кода SQL/PL SQL и "скулист" потратил 1 день, написав 5000 строчек кода на T-SQL. Понятно, что я утрирую насчет количества строк кода, но смысл думаю понятен.