Sqlite 作为 fopen() 的替代品？
在 官方 sqlite3 网页 上写着我应该考虑将 sqlite 作为 fopen() 函数的替代品。
你怎么看待这件事？ 用 sqlite 替换应用程序内部数据存储总是好的解决方案吗？ 这种解决方案的优点和缺点是什么？
你有这方面的经验吗？
编辑： 你的经历怎么样？ 这个容易用吗？ 是痛苦的还是快乐的？ 你喜欢它？
On an official sqlite3 web page there is written that I should think about sqlite as a replacement of fopen() function.
What do you think about it? Is it always good solution to replece application internal data storage with sqlite? What are the pluses and the minuses of such solution?
Do you have some experience in it?
EDIT:
How about your experience? Is it easy to use? Was it painful or rather joyful? Do you like it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这取决于。 有一些禁忌：
对于配置文件，使用纯文本或 XML 比使用关系数据库更容易调试或更改，即使是像 SQLite 这样轻量级的数据库。
使用（例如）XML 比使用关系表更容易描述树结构
SQLite API 非常糟糕记录 - 没有足够的例子，并且超链接很差。 OTOH，如果您愿意挖掘的话，信息就在那里。
直接使用应用程序特定的二进制格式比在数据库中存储与 BLOB 相同的格式更快
，如果你的内部数据与关系模型非常吻合，并且有很多数据，我会推荐 SQLite - 我自己将它用于我的一个项目。
关于经验 - 我使用它，它运行良好并且很容易与现有代码集成。 如果文档更容易浏览，我会给它 5 颗星 - 事实上我会给它四颗星。
It depends. There are some contra-indications:
for configuration files, use of plain text or XML is much easier to debug or to alter than using a relational database, even one as lightweight as SQLite.
tree structures are easier to describe using (for example) XML than by using relational tables
the SQLite API is quite badly documented - there are not enough examples, and the hyperlinking is poor. OTOH, the information is all there if you care to dig for it.
use of app-specific binary formats directly will be faster than storing same format as a BLOB in a database
database corruption can mean the los of all your data rather than that in a single bad file
OTOH, if your internal data fits in well with the relational model and if there is a a lot of it, I'd recommend SQLite - I use it myself for one of my projects.
Regarding experience - I use it, it works well and is easy to integrate with existing code. If the documentation were easier to navigate I'd give it 5 stars - as it is I'd give it four.
一如既往，没有“一刀切”的解决方案。
如果您需要将数据存储在独立文件中，并且可以利用 SQL 数据库的关系数据库功能，那么 SQLite 就很棒。
如果您的数据不太适合关系模型（例如层次结构数据），或者您希望数据易于人类阅读（配置文件），或者您需要与其他系统进行互操作，那么 SQLite 不会很有帮助，XML 可能会会更好。
另一方面，如果您需要同时从多个程序或计算机访问数据，那么 SQLite 就不是最佳选择，您需要一个“真正的”数据库服务器（MS SQL、Oracle、MySQL、PosgreSQL ...） 。
As always it depends, there are no "one size fits all" solutions
If you need to store data in a stand-alone file and you can take advantage of relational database capabilities of an SQL database than SQLite is great.
If your data is not a good fit for a relational model (hierarchical data for example) or you want your data to be humanly readable (config files) or you need to interoperate with another system than SQLite won't be very helpful and XML might be better.
If on the other hand you need to access the data from multiple programs or computers at the same time than again SQLite is not an optimal choice and you need a "real" database server (MS SQL, Oracle, MySQL, PosgreSQL ...).
SQLite 的原子性是一个优点。 知道如果您中途写入一些数据（可能在中间崩溃），它不会损坏您的数据文件。 我通常通过在成功加载时备份文件来完成与 xml 配置文件类似的操作，并且任何未来失败的加载（表示损坏）都会自动恢复上次备份。 当然，它不是那么细粒度，也不是原子的，但它足以满足我的愿望。
The atomicity of SQLite is a plus. Knowing that if you half-way write some data(maybe crash in the middle), that it won't corrupt your data file. I normally accomplish something similar with xml config files by backing up the file on a successful load, and any future failed load(indicating corruption) automatically restores the last backup. Of course it's not as granular nor is it atomic, but it is sufficient for my desires.
我发现 SQLite 使用起来很愉快，但我不认为它是 fopen() 的万能替代品。
举个例子，我刚刚编写了一个软件，它从网络服务器下载图像并将其缓存在本地。 将它们存储为单独的文件，我可以在 Windows 资源管理器中查看它们，这当然有好处。 但我需要保留 URL 和图像文件之间映射的索引才能使用缓存。
将它们存储在 SQLite 数据库中，它们都位于一个整洁的小文件中，我可以通过 URL 访问它们（从缓存中选择 imgdata，其中 url='http://foo.bar.jpg') 毫不费力。
I find SQLite a pleasure to work with, but I would not consider it a one-size-fits-all replacement for fopen().
As an example, I just wrote a piece of software that's downloading images from a web server and caching them locally. Storing them as individual files, I can watch them in Windows Explorer, which certainly has benefits. But I need to keep an index that maps between a URL and the image file in order to use the cache.
Storing them in a SQLite database, they all sit in one neat little file, and I can access them by URL (select imgdata from cache where url='http://foo.bar.jpg') with little effort.