11

在一个官方的 sqlite3 网页上写着我应该将 sqlite 视为 fopen() 函数的替代品。

你怎么看待这件事？用 sqlite 补充应用程序内部数据存储总是好的解决方案吗？这种解决方案的优缺点是什么？

你有这方面的经验吗？

编辑：你的经历怎么样？这个容易用吗？它是痛苦的还是相当快乐的？你喜欢它吗？

4

4 回答 4

10

这取决于。有一些禁忌症：

  • 对于配置文件，使用纯文本或 XML 比使用关系数据库更容易调试或更改，甚至是像 SQLite 这样轻量级的数据库。

  • 使用（例如）XML 比使用关系表更容易描述树结构

  • SQLite API 的文档记录很差——没有足够的例子，而且超链接很差。OTOH，如果您愿意挖掘，信息就在那里。

  • 直接使用特定于应用程序的二进制格式将比在数据库中存储与 BLOB 相同的格式更快

  • 数据库损坏可能意味着丢失所有数据，而不是单个坏文件中的数据

OTOH，如果您的内部数据非常适合关系模型并且如果有很多，我会推荐 SQLite - 我自己将它用于我的一个项目。

关于经验 - 我使用它，它运行良好并且易于与现有代码集成。如果文档更易于浏览，我会给它 5 颗星 - 因为它是我会给它四颗星。

于 2009-03-29T11:53:43.277 回答
4

与往常一样，没有“一刀切”的解决方案

如果您需要将数据存储在独立文件中，并且您可以利用 SQL 数据库的关系数据库功能，那么 SQLite 就很棒。

如果您的数据不适合关系模型（例如分层数据），或者您希望您的数据易于阅读（配置文件），或者您需要与另一个系统进行互操作，那么 SQLite 不会很有帮助，XML 可能会更好。

另一方面，如果您需要同时从多个程序或计算机访问数据，那么 SQLite 不是最佳选择，您需要一个“真正的”数据库服务器（MS SQL、Oracle、MySQL、PosgreSQL ...） .

于 2009-03-29T12:29:19.277 回答
1

SQLite 的原子性是一个优点。知道如果您中途写入一些数据（可能在中间崩溃），它不会损坏您的数据文件。我通常通过在成功加载时备份文件来完成与 xml 配置文件类似的操作，并且任何未来失败的加载（表明损坏）都会自动恢复上次备份。当然，它没有那么精细，也不是原子的，但它足以满足我的需求。

于 2009-03-29T12:03:11.727 回答
1

我发现使用 SQLite 很愉快，但我不会认为它是 fopen() 的万能替代品。

例如，我刚刚编写了一个从 Web 服务器下载图像并在本地缓存它们的软件。将它们存储为单独的文件，我可以在 Windows 资源管理器中观看它们，这当然有好处。但是我需要保留一个在 URL 和图像文件之间映射的索引，以便使用缓存。将它们存储在 SQLite 数据库中，它们都位于一个整洁的小文件中，我可以通过 URL（从缓存中选择 imgdata，其中 url=' http://foo.bar.jpg '）轻松访问它们。

于 2009-03-29T21:39:04.087 回答