内部使用网站：是否有针对SQLite的令人信服的案例？

许多Web框架（例如Flask或Django）都使用SQLite作为其默认数据库。 SQLite之所以引人注目，是因为它包含在python中，并且管理开销非常低。

但是，大多数高流量的公共生产站点最终都使用更重的数据库：mySQL，Oracle或postgresql。

问题：

假设：

• 站点流量适中，并且将同时进行对数据库的读/写访问
• 我们将结合使用SQLAlchemy和SQLite写锁（尽管此注释使我有些紧张）
• 该数据库可能包含60,000条记录
• 数据结构不需要在较重的数据库中发现的高级功能

对于作为中等流量内部公司工具的网站，是否存在令人信服的反对SQLite并发的案例？如果是这样，什么条件将导致SQLite出现并发问题？

我正在寻找已知的特定根本原因，而不是普遍的恐惧/未经证实的指责。

我建议阅读您问题的正式答案SQLite的适当用法。具体而言，“情况下的另一个RDBMS更好地工作”警告说，SQLite的不不支持并行写入：

SQLite支持无限数量的同时读取器，但是它只能在任何时刻允许一个写入器。在许多情况下，这不是问题。每个应用程序都会快速完成其数据库的工作并继续运行，并且锁定不会持续超过几十毫秒。但是有些应用程序需要更多的并发性，而这些应用程序可能需要寻求不同的解决方案。

从适当性的角度来看，我倾向于将SQLite视为支持SQL查询的非常复杂的文件格式。如果我想将数据库与Web应用程序分开，则倾向于避免使用SQLite，因为这种情况并未针对它进行优化。简而言之，SQLite在某些情况下没有足够的可伸缩性，因此运行那些希望有一天变得受欢迎的网站的人可能最好从可伸缩性开始，而不是使用SQLite并随后被迫切换。

综上所述，SQLite对于大多数内部网站来说可能很好。通常，内部网站不需要相同级别的并发性和可伸缩性。

戴上IT主管的帽子，我在这里看不到一些不做的事情：

• 数据损坏的风险。也许比实际情况更容易理解，但是到最后，这是一个非事务性文件类型DB，除了询问您是否有最新备份外，它没有太多（如果有的话）对不良写入的求助。说到其中。。。
• 我该如何备份呢？以某种方式，我知道我有一个很好的副本。最好不要使应用程序离线。
• 如何保护对数据库的访问？我的一般理解是，SQL lite在文件系统访问之外没有任何内容，这是一个不错的开始，但并非一帆风顺。特别是对于Web应用程序，在这些Web应用程序中，您可能需要比DBA更多的分级权限或什么都不想要。

从开发人员的角度来看，我认为了解SqlLite为什么是默认值很重要-这是因为它很容易并且演示良好。如果您要向新开发人员“出售”一个平台，那么能够以最小的热情启动一个正在运行的Web应用程序是关键。而且必须站起来并正确配置数据库服务器将是避免的巨大绊脚石。