SQLite 将其用于网站，但不用于客户端/服务器应用程序？
阅读这个问题和建议的解释何时使用 SQLite 与其他数据库更合适的链接 我仍然不清楚一件简单的事情，我希望有人能够澄清它。
他们说：
SQLite 运行良好的情况
网站
SQLite 通常可以工作 非常适合低端数据库引擎 到中等流量的网站...
...
其他 RDBMS 可能出现的情况 更好地工作
客户端/服务器 应用程序...
如果你有很多 客户端程序访问公共 通过网络的数据库...
网站不也是客户端/服务器应用程序吗？
我的意思是我不明白，网站正是一个我有许多客户端程序（具有网络浏览器的用户）通过一个服务器应用程序同时访问公共数据库的情况。
为了简单起见：归根结底，是否可以将此 SQLite 用于电子商务网站或在线目录或包含大约 1000 个产品/页面的 CMS 网站？
After reading this question and the suggested link explaining when is more appropriate to use SQLite vs another DB it's still unclear to me one simple thing, and I hope someone could clarify it.
They say:
Situations Where SQLite Works Well
Websites
SQLite usually will work
great as the database engine for low
to medium traffic websites......
Situations Where Another RDBMS May
Work BetterClient/Server
Applications...If you have many
client programs accessing a common
database over a network...
Isn't a website also a client/server app?
I mean I don't understand, a website is exactly a situation where I have many client programs (users with their web browsres) concurrently accessing a common DB via one server application.
Just to keep it simple: at the end of the day, is it possible for instance to use this SQLite for an ecommerce site or an online catalog or a CMS site with about 1000 products/pages?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
用户的网络浏览器不直接访问数据库； Web 应用程序可以。通常，用户查看的每个页面的请求/响应周期会非常快，通常持续不到一秒。
IIRC，SQLite 中的事务会锁定整个数据库文件，这意味着如果 Web 应用程序请求需要阻塞事务，则所有流量都将有效地序列化。对于中低流量的网站来说，这很好，因为每秒仍然可以处理许多请求。
然而，在客户端-服务器数据库应用程序中，多个用户可能需要长时间保持连接打开，并且还可能需要执行事务。对于较大的 RDBMS 系统来说，这不是一个问题，因为可以以更细粒度的方式执行锁定。
The users' web browsers don't directly access the database; the web application does. And normally the request/response cycle for each page the user views will be very fast, usually lasting a fraction of a second.
IIRC, a transaction in SQLite locks the whole database file, meaning that if a web app request requires a blocking transaction, all traffic will effectively be serialized. This is fine, for a low-to-medium traffic website, because many requests per second can still be handled.
In a client-server database application, however, multiple users may need to keep connections open for longer periods of time, and may also need to perform transactions. This is far less of a problem for bigger RDBMS systems because locking can be performed in a more fine-grained way.
SQLite 可以允许多个客户端读取，但只允许单个客户端写入。请参阅： https://www.sqlite.org/faq.html
客户端/服务器是什么时候多个客户端同时写入数据库，例如多个用户同时插入和更新信息的订单输入，或者多个同时编辑的多用户博客。
在只读的情况下，网站不是客户端/服务器，而只是具有多个请求的服务器。在许多情况下，网站被大量缓存，数据库甚至没有被访问，或者很少被访问。
对于一个很少使用的电子商务网站，例如几个同时购物的人，这可以由 SQLite 或 MySQL 提供支持。在某些地方，高并发数据库的性能比 SQLite 更好。
请注意，产品/页面的数量并不是确定 MySQL over SQLite 需求的好方法，而是并发用户的数量，以及在什么时候他们的并发行为会因等待锁清除而变得缓慢。
SQLite can allow multiple client reads but only single client write. See: https://www.sqlite.org/faq.html
Client/server is when multiple clients do simultaneous writes to the database, such as order entry where there are multiple users simultanously inserting and updating information, or a multi-user blog where there are multiple simultaneous editors.
A website, in the case of read-only, is not client/server but rather simply a server with multiple requests. In many cases, a website is heavily cached and the database is not even accessed, or rarely.
In the case of a slightly used ecommerce website, say a few simultaneous shoppers, this could be supported by SQLite, or by MySQL. Somewhere there is a line where performance is better for a highly-concurrent database as opposed to SQLite.
Note that the number of products/pages is not a great way to determine the requirement for MySQL over SQLite, rather it is the number of concurrent users, and at what point their concurrent behavior experiences slowness due to waiting for locks to clear.
在使用环境中，网站不一定是客户端服务器应用程序。
我认为当他们说网站时，他们的意思是网络应用程序将直接管理数据库。也就是说，数据库文件将存在于网站内，并且不会通过任何其他方式访问。 （简单地说，单点访问）
相比之下，客户端/服务器应用程序可能具有访问数据存储的网站以及另一个网站、SOAP 客户端甚至智能客户端。在这种情况下，您有多个客户端访问一个数据库（服务器）。这就是网站将成为（又一个）客户端的地方。
比较两者时要考虑的另一个方面是写入与读取的百分比是多少。我认为当与读取量相比写入量很少时，SQLite 会表现得很好。据我所知，SQLite 在多写入场景中表现不佳。它旨在供单个（少数？）进程来操纵它。
A website isn't necessarily a client server application in the context of use.
I think when they say website, they mean that the web application will directly manage the database. That is, the database file will live within the web site and will not be access via any other means. (A single point of access, put simply)
In contrast, a client/server app may have the web site accessing the data store as well as another web site, SOAP client or even a smart client. IN this context, you have multiple clients access one database (server). This is where the web site would become (yet another) client.
Another aspect to consider when constrasting the two, is what is the percentage of writes compared to reads. I think SQLite will perform happiply when there is little writing going on compared to the amount of reads. SQLite, I understand, doesn't do well in a multiple write scenario. It's intended for a single (handful?) process to be manipulating it.
我主要只在嵌入式应用程序上使用 SQLite。 （iOS、安卓）。对于更大、更复杂的网站（就像你所描述的），我会使用类似 mySQL 的东西。
I mainly only use SQLite on embedded applications. (iOS, Android). For larger, more complex websites (like your describing) I would use something like mySQL.