SQLite 与 SQL Server [英] SQLite vs SQL Server

问题描述

有人可以区分使用 SQLite 或 SQL Server 的最佳方式吗?我使用 XML 文件作为数据存储添加、删除、更新.. 有人建议使用 SQLite 进行快速操作，但我不熟悉 SQLite 我知道 SQL Server.

Would any one please differentiate what is best to use SQLite or SQL Server? I was using XML file as a data storage ADD, delete , update.. Some one suggested to use SQLite for fast operation but I am not familier with SQLite I know SQL Server.

推荐答案

SQLite 是一款出色的嵌入式数据库，可与应用程序一起部署.如果您正在编写客户将安装的分布式应用程序，那么 SQLite 的一大优势是无需任何单独的安装程序或维护程序——它只是一个与应用程序的其余部分一起部署的单个 dll.

SQLite is a great embedded database that you deploy along with your application. If you're writing a distributed application that customers will install, then SQLite has the big advantage of not having any separate installer or maintenance--it's just a single dll that gets deployed along with the rest of your application.

SQLite 也在进程中运行，并减少了数据库带来的大量开销——所有数据都在进程中缓存和查询.

SQLite also runs in process and reduces a lot of the overhead that a database brings--all data is cached and queried in-process.

SQLite 与您的 .NET 应用程序的集成比 SQL 服务器更好.您可以使用在 SQLite 引擎内运行但仍在应用程序的调用进程和空间内的任何 .NET 语言编写自定义函数，因此可以调用应用程序以在执行查询时集成其他数据或执行操作.这种非常不寻常的能力使某些操作变得更加容易.

SQLite integrates with your .NET application better than SQL server. You can write custom function in any .NET language that run inside the SQLite engine but are still within your application's calling process and space and thus can call out to your application to integrate additional data or perform actions while executing a query. This very unusual ability makes certain actions significantly easier.

SQLite 通常比 SQL Server 快很多.

SQLite is generally a lot faster than SQL Server.

然而，SQLite 一次只支持一个 writer(意味着执行单个事务).SQLite 在需要锁(读或写)时锁定整个数据库，并且一次只有一个写者可以持有写锁.由于它的速度，这对于中小型应用程序实际上不是问题，但是如果您有更高的写入量(每秒数百次)，那么它可能会成为瓶颈.有许多可能的解决方案，例如将数据库数据分离到不同的数据库中，并将写入缓存到队列中并异步写入.但是，如果您的应用程序可能会遇到这些使用要求，并且还没有为 SQLite 编写，那么最好使用其他东西，例如具有更细粒度锁定的 SQL Server.

However, SQLite only supports a single writer at a time (meaning the execution of an individual transaction). SQLite locks the entire database when it needs a lock (either read or write) and only one writer can hold a write lock at a time. Due to its speed this actually isn't a problem for low to moderate size applications, but if you have a higher volume of writes (hundreds per second) then it could become a bottleneck. There are a number of possible solutions like separating the database data into different databases and caching the writes to a queue and writing them asynchronously. However, if your application is likely to run into these usage requirements and hasn't already been written for SQLite, then it's best to use something else like SQL Server that has finer grained locking.

更新: SQLite 3.7.0 添加了一种称为预写锁定的新日志模式，该模式支持在写入时并发读取.在我们的内部多价格争用测试中，对于完全相同的争用读/写序列，时间从 110 秒变为 8 秒.

UPDATE: SQLite 3.7.0 added a new journal mode called Write Ahead Locking that supports concurrent reading while writing. In our internal multi-pricess contention test, the timing went from 110 seconds to 8 seconds for the exact same sequence of contentious reads/writes.

这篇关于SQLite 与 SQL Server的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！