我应该使用哪个数据库来存储记录，以及如何使用它？

Question

我正在开发一个应用程序，将存储大量记录。这些记录将类似于（URL、日期、标题、来源、{可选数据...}）。

由于这是一个客户端应用程序，我不想使用数据库服务器，只想将信息存储到文件中。

我希望文件可以从各种语言（至少包括Python和C++）读取，因此像Python的pickle这样的特定语言工具不适合。

我看到了两种可能性：SQLite和BerkeleyDB。由于我的用例明显不是关系型的，我倾向于选择BerkeleyDB，但我真的不知道如何使用它来存储我的记录，因为它只存储键/值对。

我的推理正确吗？如果是这样，我应该如何使用BDB来存储我的记录？你能给我提供相关信息的链接吗？或者我错过了更好的解决方案吗？

- static_rtti

---

感谢大家提供的非常有帮助的答案！选择最佳答案真的很困难 :-/ - static_rtti

Answer 1

我看到两种可能性：sqlite和BerkeleyDB。由于我的用例显然不是关系型的，我倾向于选择BerkeleyDB，但我不知道如何使用它来存储我的记录，因为它只存储键/值对。

你所描述的正是关系型数据库所要做的事情，即使你只需要一个表。SQLite可能会让这个过程变得非常容易。

编辑：关系模型与表之间的关系无关。关系是其他集合的笛卡尔积的子集。例如，实数、实数和实数的笛卡尔积（是的，所有三个）产生3D坐标空间，您可以使用公式在该空间上定义关系，例如x*y=z。每个可能的坐标集（x0，y0，z0）如果满足给定的公式，则在关系中；否则，它们不在其中。

一个关系型数据库使用这个概念，并且有一些额外的要求。首先，最重要的是，关系的大小必须是有限的。上面给出的乘积关系不满足该要求，因为有无限多个3元组满足公式。还有许多其他考虑因素，更多地与实际计算机解决实际问题的实用性或实用性有关。

更好的思考问题的方法是考虑每种持久性机制在哪些方面比另一种更有效。您已经认识到，当您拥有许多单独的数据集（表）必须相互支持关系（外键约束）时，关系型解决方案是有意义的，而这几乎不可能使用键值存储来执行。关系型的另一个真正优势是通过使用适当的索引使得富，自由查询成为可能。这是数据库层实际上理解它所代表的数据的结果。

一个键值存储系统有它自己的一套优势。其中更重要的是键值存储系统的扩展性。 Memcached, CouchDB, Hadoop 都使用键值存储，因为在多个服务器上分布键值查找很容易。另一个适合键值存储的领域是当键或值是不透明的时候，例如当存储的项被加密，只能由其所有者读取。

---

为了更好地说明关系数据库即使只需要一个表也能很好地工作，考虑以下内容（非原创）。

SELECT t1.actor1 
FROM workswith AS t1, 
     workswith AS t2, 
     workswith AS t3, 
     workswith AS t4, 
     workswith AS t5,
     workswith AS t6
WHERE t1.actor2 = t2.actor1 AND
      t2.actor2 = t3.actor1 AND
      t3.actor2 = t4.actor1 AND
      t4.actor2 = t5.actor1 AND
      t5.actor2 = t6.actor1 AND
      t6.actor2 = "Kevin Bacon";

很明显地，它使用单个表workswith来计算每个与Bacon数为6的演员。

- SingleNegationElimination

---

你能详细说明一下吗？对我来说，只有在有多个存在关系的表格时，关系型数据库才真正有意义... - static_rtti

Answer 2

伯克利数据库不错，还可以看看*DBM的变种（例如GDBM）。但是最重要的问题是：你需要通过哪些内容进行搜索？你需要按URL、一系列URL或所列日期搜索吗？

同样，可以将记录组织成简单的文件存储在本地文件系统中，按日期或搜索词汇等分组。

回答“搜索”问题是最重要的开始。

至于键/值问题，您需要确保KEY本身在查找方面定义良好。例如，如果您有时需要按日期查找，而其他时间则按标题查找，那么您将需要维护一个“记录”行，然后可能需要两个或更多“索引”行以引用原始记录。几乎可以将任何东西建模为键/值存储。

- Jé Queue

---

你几乎可以在键/值存储中建模任何东西。你能推荐一些相关阅读材料吗？我知道这个模型非常通用，但是阅读一些例子会很有帮助。 - static_rtti

我可以找到一些内容，但传统的底层数据库存储基础实际上是以某种机制为键/值存储。堆表只是将行写入键/值中，其中行作为值，键是某种生成的ROWID。在这样的表上的非复合索引将索引的值列出作为键，ROWID作为值。当然，情况会变得更加复杂，但是“没有什么东西是不能通过另一层间接性来解决”的原则也适用于此。如果我能找到一些文章，我会回复评论。 - Jé Queue

Answer 3

个人而言，我会选择使用sqlite。它一直对我（以及我一起工作的其他人）非常好用。当您的应用程序变得更加复杂时，您不必重写代码。

另一方面，我在Python开发人员列表中看到了有关Berkely DB的各种评论，表明它并不完美；您只能获得字典式访问（如果您想要选择特定的日期范围或标题而不是URL怎么办）；并且它甚至不在Python 3的标准库中。

- andrew cooke

---

"甚至在Python 3的标准库中都没有。" 不知道这点，这是一个非常好的观点，谢谢！ - static_rtti

请检查。我看了一下，我能看到（g | n）dbm支持，但我认为那是不同的，对吗？也许我记得开发人员列表中的讨论是与其放弃相关的。 - andrew cooke

Answer 4

MongoDB 怎么样？我还没有尝试过，但它似乎很有趣。

- Bastien Léonard

---

看起来很有趣... 但似乎还不够成熟。 - static_rtti

Answer 5

如果您只想使用单个字段来查找记录，那么简单的键值存储是一个不错的选择。将该单个字段（或任何其他唯一ID）作为键，将每个记录序列化为字符串（使用JSON或类似方法），并将该字符串作为值存储。Berkeley DB肯定是键值存储的一个合理选择，但有许多其他选择可供选择： http://en.wikipedia.org/wiki/Dbm

如果您想通过多个字段之一查找记录，则对于开发目的，SQLite可能是最容易的选择。您将在SQL中编写查询，但无需维护数据库服务器。所有多键机制已经为您编写好了。

如果你真的想避免使用SQL或者从你的数据存储中挤出每一点性能，并且你需要多键访问，那么请考虑在键值存储之上添加一层额外的逻辑。通过序列化记录并将每个记录的“列”值作为附加键插入到值中，可以在键值存储之上构建类似列的行为，这些键的值包含记录的“主”键。（实际上，您正在将键值存储用作记录字典和查找这些记录的索引字典。）Google的App Engine就是这样做的。你可以自己做，也可以使用各种文档导向型数据库来完成。如果你想阅读一些有趣的内容，请尝试谷歌搜索“nosql”。http://www.google.com/search?&q=nosql

- ʇsәɹoɈ

---

请注意，Python发行版中的Berkeley DB只是因为bdb库内部更改频率比Python开发人员想要跟上的频率更高。这并不意味着Berkeley DB不好，只是直接集成到Python发布版本中有些麻烦。您仍然可以将bdb Python绑定作为单独的模块获取。 - ʇsәɹoɈ

Answer 6

好的，你说只是存储数据吗？实际上，你只需要一个数据库来检索、查找、汇总等操作。因此，对于存储，只需使用简单的文本文件并追加行即可。如果需要，可以压缩数据，在字段之间使用分隔符 - 几乎任何语言都能读取这样的文件。如果您确实想要检索数据，则应专注于您的检索需求，例如按日期、按关键字、哪些关键字等。如果您需要简单的客户端，则需要简单的客户端数据库。SQLite比BDB容易得多，但请考虑诸如Sybase Advantage（非常快速且免费提供本地客户端，但不是开源）或VistaDB或Firebird等内容...但所有这些都需要本地配置/设置/维护。如果您选择本地XML，对于“大量”记录，将会给您带来一些不必要的膨胀文件大小..！

- andora