MySQL по сравнению с SQL Server по сравнению с [закрытой] Oracle

ПРИМЕЧАНИЕ. Я ничего не могу сказать о Oracle, поэтому я отвечу только за SQL Server.

Ну, конечно, незначительные различия в ядре базы данных, такие как оператор MERGE, BULK INSERT, GROUPING SETs и т. Д.

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

Some other things which oracle has over mysql.

• Queues
• internal job scheduling
• mature stored procedure language
• patitioned tables
• fine grained access control and auditing
• strong recovery features ( eg flashback, rman, dataguard )
• remote database links
• application express

Чистые слои СУБД Oracle и MSSQL предлагают в основном более зрелую программируемую среду, чем MySQL и InnoDB. T-SQL и PL / SQL еще не могут быть сопоставлены хранимыми процедурами и триггерами MySQL.

Другими отличиями являются синтаксические и небольшие семантические различия, которые упрощают или усложняют задачу (например, топ-500 по сравнению с лимитом / смещением).

Но настоящий убийца заключается в том, что есть тонна интегрированных инструментов и сервисов поверх Уровни СУБД MSSQL (службы отчетов, службы анализа) и Oracle (хранилища данных, RAC), которых в MySQL нет (пока).

There are too many functionality to list. See Wikipedia reference in nullptr's message. But I suppose that really question asked at meeting is "To a developer, what earth-shaking functionality do MS or Oracle offer that MySQL lags in which allows MS and Oracle to charge for their systems and which can be effectively utilized by our company?"

All advantages are really advantages if matched with your needs ...

I think the question has the implicit assumption that it is development features that allows SQL Server/Oracle to charge. I suspect that it is more the implementation/support.

Hot backup is a major feature that is worth paying for, at least for most installations.

For Oracle, a big added value is RAC - multiple servers hitting the same data (ie same disks) without any messy replication involved. It (generally) isn't apparent to the developer.

Вдохновленный ответом ThinkJet, я думаю, что в игру вступает еще один фактор: «В какой степени мы готовы отказаться от независимости баз данных, чтобы обеспечить более быструю и дешевую разработку более производительных приложений?» Если компания делает упор на то, что весь код должен быть переносимым между базами данных, тогда нет смысла использовать что-либо, кроме самой простой СУБД, а улучшения и преимущества, которые предоставили Oracle и Microsoft, ничего не значат.

MySQL не предлагал более богатую среду программирования, которую предлагали Oracle и MSSQL, особенно в ранних воплощениях, когда в ней даже не было хранимых процедур. С моей точки зрения, я склонен помещать большую часть своей бизнес-логики в приложение через DAO или ORM-преобразователи и т. Д. Следовательно, ядро ​​базы данных менее важно, и теоретически приложение переносимо. С точки зрения управления MSSQL предлагает ряд преимуществ (многие из которых уже перечислены), которые значительно упрощают задачу владения базой данных. Microsoft также предоставляет отличный и легкий SQLExpress для разработки, с которым мне легко работать, и он прекрасно интегрируется в Visual Studio.

Некоторые функции Oracle, которые мне действительно нравятся, - это

• Real Application Clusters, довольно мощный способ создания кластеров баз данных
• Быстро обновляемые материализованные представления, очень эффективный способ хранения и обновления результатов запросов.
• Аналитические функции (также известные как оконные функции), которые позволяют эффективно группировать функции по подмножеству результатов запроса. Это позволяет избежать самосоединения в большинстве случаев.

Насколько мне известно, ничего из этого не доступно в MySQL. И есть еще много полезных функций, особенно в корпоративной версии и ее опциях.

До тех пор, пока я не администрировал RDBS от других поставщиков, Oracle часто повторяла, что "читатели не блокируют писателей, писатели не блокируют читателей" мало что значило для меня. Я действительно мало знал об обработке блокировки проблемы за 8 лет работы в качестве администратора баз данных Oracle. 2 года работы с Informix и 3 или SQL Server, и поверьте мне, я знаю гораздо больше о блокировках.

Поэтому я бы сказал, в дополнение к комментариям о поддержке и функциях, не связанных с СУБД, добавьте поведение блокировки.

Кластеры Oracle table clusters и single table hash clusters (которые вы также не найдете в SQL Server)