我从另一个问题中得到了这个.
在sqlite的适当用途下,它具有:
SQLite运行良好的情况
•网站
SQLite通常可以作为中低流量网站的数据库引擎(也就是所有网站的99.9%).当然,SQLite可以处理的Web流量大小取决于网站使用其数据库的程度.一般来说,每天点击次数少于100K的网站应该可以正常使用SQLite.100K点击/天的数字是一个保守估计,而不是一个硬上限.SQLite已被证明可以使用10倍的流量.
另一个RDBMS可以更好地工作的情况
•客户/服务器应用程序
如果您有许多客户端程序通过网络访问公共数据库,则应考虑使用客户端/服务器数据库引擎而不是SQLite.SQLite将在网络文件系统上运行,但由于与大多数网络文件系统相关的延迟,性能不会很好.此外,许多网络文件系统实现的文件锁定逻辑包含错误(在Unix和Windows上).如果文件锁定不能正常工作,则两个或多个客户端程序可能同时修改同一数据库的同一部分,从而导致数据库损坏.由于此问题是由底层文件系统实现中的错误引起的,因此SQLite无法阻止它.
一个好的经验法则是,在通过网络文件系统从多台计算机同时访问同一数据库的情况下,应避免使用SQLite.
我将在这里展示我的无知,但这两者之间的区别是什么?
"Web应用程序"是指浏览器通常用作客户端的应用程序.Web应用程序是客户端/服务器应用程序.换句话说,您可以将客户端/服务器应用程序视为超类,其中Web应用程序是子类.
"web"应用程序意味着浏览器是客户端
客户端/服务器应用意味着自定义客户端应用.认为Outlook挂钩交换,而它可能使用网络连接,它是自己的客户端到交换服务器.
编辑:
更具体的是您发布的sqlite文本,它们的意思是客户端应用程序不应该直接访问您的sqllite数据库,而应该使用某种服务器端接口(即json Web服务)
但在我看来,这个经验法则适用于所有数据库引擎.如果我使用SQL Server或Oracle,我肯定会避免让客户端应用程序直接连接到数据库,这有很多潜在的问题,首先是安全性.
有一些不同的注意事项:
Web应用程序假设客户端是Web浏览器,客户端和服务器之间的通信是无状态的(HTTP).它还倾向于假设客户端"瘦"并且在浏览器中完成很少的信息处理.
客户端 - 服务器应用程序假设客户端是"胖"客户端,并且客户端和服务器之间的通信保持状态(这不一定是真的).通信几乎可以是任何协议.老式的客户端服务器或2层应用程序确实让每个客户端直接连接到数据库 - 我会建议不要出于各种原因,排名第一的是安全性.这可能是您在发表SQLite不合适时所发布的内容.
3 +层类型的应用程序仍然可以具有状态客户端 - 服务器通信,但中间层将处理实际的数据库通信.在这种情况下,网络上的延迟并不重要,SQLite可以工作(因为它更像是一个Web应用程序).