Различия зависят от ваших намерений - если вы действительно не хотите просто исчерпывающий список белья. Другими словами, кажется, что вы действительно хотите спросить о значительных различиях, а значимость зависит от цели.
Я полагаю, что большинство людей, как правило, считают несколько конкретных вещей существенными:
- производительности
- Совместимость
- Портативность
- расширенные функции
- простота использования
- стоимость
Относительная значимость этих характеристик базы данных зависит, в основном, от того, находится ли его намерение в программировании в большом или в маленьком . Поскольку я в основном работаю в мире программирования в целом, я буду говорить оттуда. Когда я работаю (как правило, над своими проектами) в мире программирования в малом, я обычно все еще склоняюсь к своим решениям для мира в целом, так как я нахожу это достаточно легким и предпочитаю спасать себя от головные боли передумали позже, когда мой проект вырос. Я заметил, что многие проекты с открытым исходным кодом страдают от огромных, иногда фатальных, проблем с ростом, когда их последующие действия заставляют их переступить порог от маленького к большому.
Мое первое беспокойство заключается в том, что я всегда должен иметь возможность передумать по поводу выбора поставщика базы данных и продукта, поэтому совместимость - это главное, а переносимость - это королева. Имея это в виду, я настоятельно предпочитаю обращаться с базой данных только как с носителем данных, поэтому я избегаю помещать любой код в базу данных и избегать любых функций, которые не относятся к хранилищу или относятся к конкретному поставщику или продукту. Для СУБД совместимость в первую очередь означает соответствие стандарту ANSI SQL, поэтому я немедленно отклоняю любой продукт, который не является достаточно разумным. Поскольку я работаю в мире Linux, Unix и Windows, переносимость означает доступность на всех этих платформах.
Мой код принадлежит вместе и в лучшем для него окружении - не разделен на искалеченную среду движка базы данных; еще один аспект того, что значит рассматривать базу данных как просто носитель данных. Поэтому функции кодирования имеют для меня ограниченное отношение. В очень редких случаях я буду создавать в базе данных код для триггера или некоторых удобных функций, поэтому я ожидаю соответствия стандарту ANSI SQL для основных возможностей, и это все.
У меня обычно много данных, поэтому производительность важна, и я хочу обменяться некоторой простотой использования, чтобы получить ее. Я не возражаю против тяжелой установки базы данных или сложной структуры базы данных, если у меня есть некоторые базовые инструменты для упрощения и автоматизации процесса. Это означает, что я должен быть в состоянии написать сценарий установки механизма базы данных (двоичных файлов), а также структуры и данных моей базы данных. Принудительно использовать GUI, как единственный вариант, для важных задач базы данных недопустимо.
Иногда, обычно во имя производительности, я считаю необходимым использовать определенную функцию, которая приводит меня к конкретному поставщику или даже к определенному продукту. Я делаю все возможное, чтобы изолировать эту зависимость и сохранить возможность выбора другого поставщика или продукта, не жертвуя преимуществами этой специальной функции. Я мог бы даже построить целую систему на основе особой ценности, получаемой из такой специфичной для поставщика или специфической для продукта функции, но только явным образом согласившись с затратами на это. Кажется, что стоимость ограничения опционов перевешивает любые другие формы затрат.
Очевидно, что цена покупки ядра базы данных - это стоимость, но и потеря свободы в ее использовании. Поэтому я очень высоко ценю продукты с открытым исходным кодом.
Наконец, меня часто ограничивают решения других, таких как мои клиенты. Поэтому я также стараюсь быть гибким в принятии решений, которые я бы не сделал сам.
Учитывая все это, я предпочитаю ядро базы данных SQLite, потому что его совместимость, переносимость и свобода использования затмевают все остальные.
Во-вторых, я люблю Oracle и предпочитаю его для программирования в целом. Это не дешево, но может сделать все, что мне может понадобиться, с наилучшим сочетанием совместимости, портативности, производительности и функций.
В-третьих, я использую Microsoft SQL Server, когда это требуется моим клиентам. Я поддерживаю мастерство и совместимость с ним, потому что он слишком доминирует на рынке, чтобы его игнорировать. Возможно, у меня даже есть особая функция, которая мне когда-нибудь понадобится, хотя я еще не сталкивался с такой ситуацией.
Я избегаю MySQL из-за его несовместимости, но я часто поддерживаю его как чей-то выбор. Я считал это своим основным предпочтением, но мой глубокий анализ его характеристик показал, что нельзя легко сместить базу кода между ней и любой ANSI-SQL-совместимой СУБД. Для меня это совершенно неприемлемо.
Кстати, моя цель для такого перехода на другой движок базы данных - от нескольких минут до недели (сорок часов). Поскольку я обертываю свой доступ к базе данных слоем совместимости, я обнаружил, что обычно я могу переключать ядра базы данных в течение максимум нескольких часов. Часто мои приложения могут поддерживать несколько механизмов баз данных одновременно (путем простого изменения конфигурации при запуске).
С наилучшими пожеланиями.