Почему SQL не так широко распространен в больших настольных приложениях?

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

Теперь мне интересно несколько вещей о базах данных и их использовании в общих приложениях:

• Почему сама Windows не использует «центральную» базу данных SQL? Например:
  • Данные об ошибках хранятся в куче файлов,
  • Центр обновления Windows хранит все в плоских файлах,
  • Кэш иконок хранится в очень странном отдельном файле, к которому нет доступа через SQL и т. Д.
• Почему так много больших приложений избегают использования баз данных? Например, разве Microsoft Outlook не выиграет от использования реальной базы данных вместо того, чтобы заново изобретать колесо, имея собственный формат для файлов PST и сохраняя некоторые данные в реестре?

Если база данных добавляет дополнительный уровень общей сложности и незначительную потерю производительности, это цена огромного преимущества упрощения кода в большинстве случаев, особенно когда речь идет о хранении небольших организованных блоков данных вместо больших двоичных файлов. потоки. Так почему же так мало продуктов на самом деле используют базы данных? Вероятно, единственное приложение, которое я знаю, которое на самом деле использует базу данных Sqlite, - это Firefox и, возможно, Microsoft Exchange (но последнее не является настольным приложением)?

Кроме того, ряд приложений, таких как Microsoft Office или Microsoft Expression, не выиграют от наличия единой базы данных SQL , упрощающей развертывание приложений, обновление / обновление данных, обмен данными между этими приложениями, создание резервных копий. , так далее.?

1) Вообще говоря, накладные расходы на запуск полной СУБД слишком велики, и это добавит ненужную нагрузку на систему и усложнит ее.

Его установка делает вашу жизнь проще как разработчика, но ухудшает жизнь владельца машины, так как его машина, вероятно, будет работать медленнее и с большим количеством проблем. В противостоянии разработчиков и пользователей пользователь должен почти всегда побеждать.

2) Многие хранилища данных имеют особые потребности, которые не удовлетворяются чем-то вроде SQL Server Express.

Например, журналы ошибок должны быть записаны как можно проще, чтобы максимизировать вероятность того, что запись произойдет и данные будут доступны. SQL Server никогда не будет таким простым.

Для более сложных приложений аргумент, как правило, больше сводится к оптимизации для очень специфических пользовательских случаев - плоские файлы могут быть молниеносно быстрыми.

Многие приложения встраивают SQLite . Цитирование с их сайта:

SQLite - это программная библиотека, которая реализует автономный, безсерверный, транзакционный механизм базы данных SQL с нулевой конфигурацией. SQLite - это наиболее широко используемый в мире механизм баз данных SQL. Исходный код SQLite находится в открытом доступе. "

Вы просто используете один из доступных API-интерфейсов, создаете базу данных, таблицы и т. Д., И механизм SQL сохраняет все в двоичном файле, который вы можете поместить в любое место в файловой системе пользователя. Лучше всего, это нить.

Windows поставляется с и использует ядро ​​базы данных с именем Extensible Storage Engine (ESE) .

ESE используется Active Directory, Exchange Server, Windows Mail и Desktop Search среди многих других служб и приложений Windows.

Для разработки существуют открытые оболочки ESE:

• ESE C # / C ++ инструментарий 1.2
• ManagedEsent для .NET

С ESE, поставляемой с каждой современной версией Windows, у вас нет проблем с развертыванием базы данных. Архитектурно ESE выполняет ту же роль, что и встроенные базы данных, такие как SQLite.

Реляционные базы данных - не самая эффективная структура данных для каждого домена. Многие настольные приложения используют встроенные базы данных, вы просто не можете сказать, что они делают это, если все, что вы видите, это пара файлов данных.

Почему сама Windows не использует «центральную» базу данных SQL?

На самом деле, эта идея была в разработке в Microsoft в течение некоторого времени. Это называется WinFS . Это интригующая технология, и она доступна подписчикам MSDN. Через несколько дней я собираюсь установить ее на ВМ и поиграть с ней.

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

Базы данных также хорошо справляются с обработкой нескольких соединений / входов. Опять же, если это не является обязательным требованием для вашего настольного приложения, зачем добавлять дополнительную сложность? Сколько других приложений или пользователей пытаются записать файл Outlook на вашем компьютере, кроме как через пользовательский интерфейс / фактическую установку самого Outlook?

Было бы проще, если бы все данные находились в реляционной базе данных из «Я хочу иметь возможность запрашивать все данные любым подходящим способом с точки зрения одного языка, такого как SQL», но это редко является приоритетом для многих приложений.

Большинство программистов будут смотреть на это из:

• Я знаю, что приложение должно делать, это все, что нужно сделать

• мое приложение - единственное право, которое когда-либо получит доступ и / или манипулирует этими данными

• будет работать простая структура файла моего собственного дизайна

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