是否有人在LAN（Windows或Linux）上的SMB共享上运行Sqlite数据库方面有实际经验？
从documentation可以清楚地看出，这并不是共享Sqlite数据库的最快方式。
显而易见的警告是它可能很慢，而且Sqlite一次只支持一个写入数据库的线程。因此，您的并发更少，因此您的数据库更新现在将阻止数据库更长时间（数据在网络上传输时数据库将被锁定）。
对于我的应用程序，我想要共享的数据量相当小，并且写入次数不太频繁（最多每隔几秒写一次）。
我应该注意什么？这可以吗？
我知道这不是Sqlite的设计目标，我对基于Postgres / MySql / Sql Server的解决方案不太感兴趣，因为我试图尽可能少地依赖我的应用程序。
相关链接：
来自sqlite mailing list，所以我想一个大问题是SMB（windows或linux）上的文件锁apis有多不可靠
答案 0 :(得分：27)
我对基于文件的数据库（即那些没有数据库服务器进程的数据库）的经验，可以追溯到二十多年，如果你试图分享它们，它们将不可避免地最终被破坏。我强烈建议你再看看MySQL。
请注意，我不是在选择SQLite - 我自己使用它，而不是作为共享数据库。
答案 1 :(得分：9)
嗯，我不是伟大的sqlite专家，但我相信锁定记录/表可能无法正常工作，并可能使数据库损坏。因为没有单个服务器维护中央锁定，所以在网络上共享同一文件的不同机器上的两个sqlite dll实例可能根本无法正常工作。如果数据库在同一台机器上打开，sqlite可能会使用操作系统提供的文件级别锁定来保持完整性，但我怀疑它是否能够在网络共享上正常工作。
答案 2 :(得分：8)
＆＃34;如果您有许多客户端程序通过a访问公共数据库 在网络中，您应该考虑使用客户端/服务器数据库引擎 而不是SQLite。 SQLite将在网络文件系统上运行，但是 由于与大多数网络文件系统相关的延迟， 表现不会很好。另外，文件锁定逻辑很多 网络文件系统实现包含bug（在Unix和Unix上） 视窗）。如果文件锁定不起作用，它可能是 两个或多个客户端程序可以修改相同的部分 同一个数据库同时导致数据库损坏。 因为此问题是由底层文件系统中的错误引起的 实现时，SQLite无法阻止它。＆＃34;
来自https://www.sqlite.org/whentouse.html
也适用于任何类型的基于文件的数据库，如Microsoft Access
答案 3 :(得分：4)
您要求获得真实的体验。这里有一些：
SQLite锁定是健壮的，ASSUMING底层（联网）文件系统也很健壮。从历史上看，这是一个糟糕的假设。最近的操作系统让它变得更好。
如果按照规则玩游戏，那么最大的问题就是数据库停留在锁定状态＆＃34;连续几分钟。例如，如果网络丢弃＆＃34;解锁＆＃34;来自读者的请求，您可能无法在锁定到期之前写入。如果＆＃34;解锁＆＃34;从作家失踪，你将无法阅读。 （公平地说，你可以在普通文件中遇到同样的问题。）
通过＆＃34;机会锁定＆＃34;您可以在良好可靠的网络上获得更少的问题。 （数据库已禁用（客户端级文件缓存）。