为什么SQL在大型桌面应用程序中没有那么广泛？

作为软件开发人员，我从事过从小型自制应用程序到中型企业应用程序的项目。在几乎每个项目中，我都使用一个数据库，或者后悔从一开始就选择不使用它。

现在，我想知道有关数据库及其在一般应用程序中的用法的一些信息：

• 为什么Windows本身不使用任何“中央” SQL数据库？例如：
  • 错误报告数据存储在许多文件中，
  • Windows Update将所有内容存储在平面文件中，
  • 图标缓存存储在一个非常奇怪的单个文件中，该文件似乎无法通过SQL等访问。
• 为什么这么多大型应用程序避免使用数据库？例如，Microsoft Outlook不会通过使用真实的数据库而不是通过使用自己的.pst文件格式并将某些数据存储在注册表中来重新发明轮子而获益吗？

如果数据库增加了总体复杂性和微小的性能损失，那么在大多数情况下，使代码变得更简单，这是巨大优势的代价，尤其是在存储小的组织化数据块而不是大型二进制数据时流。那么，为什么这么少的产品实际使用数据库呢？我知道的唯一实际使用Sqlite数据库的应用程序是Firefox，也许是Microsoft Exchange（但最后一个不是桌面应用程序）？

此外，拥有统一的SQL数据库，使部署应用程序，更新/升级数据，在这些应用程序之间共享数据，进行备份变得更加容易，Microsoft Office或Microsoft Expression等应用程序集也不会受益。等等？

1）一般来说，运行完整的RDBMS的开销太大，会给系统增加不必要的负载，增加复杂性。

安装一台计算机会使您作为开发人员的生活更加轻松，但是由于计算机的运行速度可能会变慢且出现更多问题，因此会使计算机所有者的生活变得更糟。在开发人员与用户的对抗中，用户几乎应该总是赢。

2）许多数据存储具有特定的需求，而SQL Server Express之类的东西无法满足这些需求。

例如，应该将错误日志写入最简单的可能事物，以最大程度地实现写入和数据可用的机会。SQL Server永远不会那么简单。

对于更复杂的应用程序，争论更多地集中在针对非常特定的用户案例进行优化-平面文件的处理速度很快。

许多应用程序都嵌入了SQLite。从他们的网站报价：

SQLite是一个软件库，可实现自包含，无服务器，零配置的事务型SQL数据库引擎。SQLite是世界上部署最广泛的SQL数据库引擎。SQLite的源代码在公共领域。”。

您只需使用一种可用的API，创建数据库，表等，SQL引擎就会将所有内容存储在二进制文件中，您可以将其放在用户文件系统中的任何位置。最重要的是，牙线。

Windows附带并使用一个名为可扩展存储引擎（ESE）的数据库引擎。

Active Directory，Exchange Server，Windows Mail和桌面搜索以及许多其他Windows服务和应用程序都使用ESE。

对于开发，存在开源ESE包装器：

• ESE C＃/ C ++工具箱1.2
• NET的ManagedEsent

随ESE随Windows的每个现代版本一起提供时，您无需担心数据库部署。从结构上讲，ESE扮演着与嵌入式数据库（例如SQLite）相似的角色。

关系数据库并不是每个域中最有效的数据结构。许多台式机应用程序确实使用嵌入式数据库，如果您只看到几个数据文件，就无法轻易地说出它们正在这样做。

为什么Windows本身不使用任何“中央” SQL数据库？

实际上，这个想法已经在Microsoft开发了一段时间。它称为WinFS。它是一种有趣的技术，并且可供MSDN订户使用。几天后，我打算将其安装在VM上并使用它。

数据库提供了灵活性，就像每项功能一样，几乎肯定要付出代价。如果可以使用平面文件，则可以假设没有人需要像临时报告中那样以意外方式查询数据。

数据库在处理多个连接/输入方面也做得很好。同样，如果这不是您的桌面应用程序所必需的，为什么还要增加额外的复杂性？除了通过用户界面/ Outlook本身的实际安装以外，还有多少其他应用程序或用户正在尝试写入计算机上的Outlook文件？

如果所有数据都从“我希望能够以我认为适合的单一语言（如SQL）查询所有数据”的关系数据存储在关系数据库中，则会更容易，但这在许多应用程序中很少是优先事项。

大多数程序员将从以下方面进行查看：

• 我知道该应用程序应该做什么，这就是所有要做的事情

• 我的应用是唯一可以访问和/或操纵这些数据的实体

• 我自己设计的简单文件结构将起作用

• 对于至少一个应用程序，我想避免依赖他人的代码并拥有完全的控制权。