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

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

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

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

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

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

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

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

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

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

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

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


LetsCodeIt, 24 мая 2023 г., 13:30