是不是SQLite有点被低估了？[关闭]

在提出问题之前，让我首先描述一下我对SQLite的看法。

我碰巧喜欢小型，快速且更重要的是仅具有真正必要功能的工具。这就是为什么我喜欢SQLite而不喜欢MS-SQL的原因。

例如：MS-SQL可能具有更多的功能，可伸缩性等，但是如果您不走运，安装它也会很麻烦。当然，我并不是说安装困难是不选择特定数据库的原因。

不能误解我的意思：MS-SQL是优质产品。我对MS-SQL很有经验；我非常了解产品。我只是不太喜欢它，而在某些情况下并不需要它（=没有多少用户，<10-15）。

您实际上使用了多少数据库功能？以我的经验，它通常只是普通的SQL（SELECT，INSERT和UPDATE）。

我喜欢SQLite。快速着迷。“安装”非常容易。我认为SQLite可以做的比声明的要多。为什么只将其用于单进程/单个用户应用程序？毕竟：没有多少应用程序会不断访问数据库。

例如：考虑一个有15个用户的ERP应用程序。为什么不能使用SQLite？让我们面对现实吧：以我的专业经验，大多数时间，此类应用程序的用户访问数据库的时间将占他们使用该应用程序的总时间的5-10％。在另外90-95％的区域中，他们只是看着屏幕上的信息，以表格/表格形式输入数据，并且保存输入的时间不超过数据库时间的1秒。铁：1.5分钟的输入时间与1秒的保存时间。

如果SQLite数据库文件在“节省时间”期间被锁定，则需要访问数据库的其他用户只会等待，但他们不会注意到，因为等待时间会非常短（不明显）。在代码中，您只需要处理数据库可能的“繁忙”时间，以避免出现异常，但这并不难做到。

有些人必须像我一样思考，甚至​​为SQLite构建了一个客户端-服务器解决方案：SQLitening。这使我更加相信自己可能不会自欺欺人。

当然，有些数据库密集型应用程序不适合使用SQLite。但是，正如我现在考虑的那样，许多多用户应用程序（如果它们不超过15个用户）应该可以很好地使用SQLite。

我们的许多客户在硬件上的花费并不多，因此我经常遇到一台服务器，上面有所有东西（Exchange，SQL，客户端等），因此几乎“气喘吁吁”。如果我可以提供对系统要求不高的产品，那么我的客户将很高兴。SQLite不会增加任何权重（至少不会增加多少），​​MS-SQL会增加。因此，我不会选择SQLite，因为它是免费，便宜或易于安装的。我出于实际/技术原因会选择它。

仅供参考：根据我的专业，我们向客户销售产品（自定义和标准产品，主要是与ERP相关的产品），平均而言，使用该产品的客户不超过5-6人。有一些例外，但用户数不能超过10-15。

问题是：我是否认为可以将SQLite用于某些多用户应用程序（如我所描述的示例）正确吗？我应该知道什么技术上的缺点吗？您有哪些经验（负面或正面）可以帮助我做出正确的选择？

更新：请不要将此视为对其他数据库的负面判断。它们大多都是优质产品。只是在这里分享我的想法并对您对此的看法感兴趣。

在很多情况下，SQLite都很丰富。用户，部门或公司很少将其淘汰（我们对此了解不多，因为如果应用程序运行良好，则没人会调用程序员。）对于MS Access文件（Windows）或SQL Server Compact Edition（需要某些安装）。它们对于本地应用程序都足够好，因为您不必太担心文件的安全性。

在本地网络上的多用户场景中，文件将转到所有用户都需要访问的共享文件夹-呼叫安全性。简单的维护或任何表结构的更改（例如备份或添加列）都将阻止其他用户访问。昨晚备份失败，因为有人忘记退出该应用程序。当您想在一天中进行备份时会发生什么？每个人都有理由认为，由于数据库的技术限制，他们白天不需要任何备份。在某些时候，在您的服务器上安装SQL Server Express /其他等效版本将需要一些初始设置和安全性配置，这在前面就涉及更多，但是几乎不需要维护。

始终存在对可伸缩性/过度设计的担忧。即使用户数量或数据量仍可管理，但总有人会想到利用某个Intranet或其他网站/浏览器界面上的实时数据。文件数据库存在问题。只有一个想要通过VPN访问数据文件的人（该应用程序安装在他们的笔记本电脑上）才能为您解决“扩展”问题。您可以构建该应用程序，以允许断开连接的用户返回时可以同步。对于偶尔不在办公室的用户来说，这似乎并不值得。

我认为，当您需要“内部”数据库时，使用它会很棒。也就是说，您的应用程序/代码将与之交互的数据库，但不会与您的应用程序存在的主要原因直接相关。除了使用庞大的内存映射或高速缓存管理器之外，您还可以使用此类数据库。我有一个非常具体的例子，最近我在JUnit / DBunit测试用例中使用了它，我需要连接到数据库，执行一些工作，读取数据并最后擦除所有内容。由于您只需要创建一个空文件来创建数据库，这很容易做到。

我看到的另一种用法是：只有一个用户时。是的，有可能，例如以“ Firefox”或“ Opera”为例：-)

另外，在SQLite网站上，他们对此非常诚实，并给出了何时不使用它的原因（请参见“其他RDBMS可能会更好地工作的情况”一节）

ps：与Sql Server Express上的注释有关，是的，需要“安装”。而且，我个人更新时遇到了一些麻烦（我必须手动删除一些与先前版本相关的注册表项，才能安装2008 R2）。但是，如果要将SQLite与Microsoft开发的数据库进行比较，请查看不需要安装的Sql Server Compact Edition（请参阅“基于私有文件的部署”）。

例如：考虑一个有15个用户的ERP应用程序。为什么不能使用SQLite？

很少有应用程序永远拥有很少的用户。对于看到更多用户和更复杂数据操作的用户，由于简单的“一次一次写入事务”锁定模型，出于性能原因，完全不使用SQLite。

假设您有100位用户，每位用户工作60秒，然后填写表格，然后提交。因此，您需要每秒处理约1.6个事务。数据模型很复杂，保存表单涉及到读取和写入许多大表，甚至可能与不同的系统进行通信，因此，每个“提交表单”都需要2秒钟的时间进行交易。但是SQLite不能同时处理事务，因此这意味着它每秒只能处理0.5个事务。哎呀

“安装可能会很痛苦”并不是决定采用关键基础架构的充分理由。此外，还有其他数据库引擎可供选择，其中至少有两个（MySQL和Postgres）是免费的，并且没有SQLite的并发限制。它们甚至可能比MS-SQL更容易安装。

我认为SQLLite对于应用程序开发非常有用，它的最大优势是不需要在客户端上安装它。

但是，也不要小看SQL Server Express，它是一个免费的优秀数据库，具有普通sql Server的大多数功能，但数据库大小有限（很难超过），并且能够使用常规的出色工具sql服务器。

最大的缺点是您需要安装它，尽管我对此部分尚不确定，但现在可能可以解决

如果您每小时要处理几GB的数据，我不认为SQLite是一个严肃的数据库。它变得非常缓慢，并降低了整个应用程序的性能。抱歉，但我不同意您对SQLite的迷恋:-)

数据库的问题在于它们倾向于累积越来越多的数据。选择轻量级数据库会带来您的工具无法正确扩展的风险。