我应该使用哪个数据库来存储记录,我应该如何使用它?

时间:2009-11-08 17:01:35

标签: c++ python database persistence

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

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

我希望这些文件可以从各种语言中读取(至少是python和C ++),所以特定语言如python的pickle就不在游戏中了。

我看到两种可能性:sqlite和BerkeleyDB。由于我的用例显然不是关系型的,我很想和BerkeleyDB一起使用,但我真的不知道如何使用它来存储我的记录,因为它只存储键/值对。

我的推理是否正确?如果是这样,我应该如何使用BDB存储我的记录?你能把我链接到相关信息吗?或者我错过了一个更好的解决方案?

6 个答案:

答案 0 :(得分:5)

  

我看到两种可能性:sqlite   和BerkeleyDB。就像我的用例一样   显然不是关系,我很受诱惑   和BerkeleyDB一起去,但我没有   真的知道我应该如何使用它   存储我的记录,因为它只存储   键/值对。

您所描述的正是关系的内容,即使您只需要一张桌子。 SQLite可能会让这很容易做到。

编辑:关系模型与表之间的关系没有任何关系。关系是其他集合的笛卡尔积的子集。例如,实数,实数和实数的笛卡尔积(是的,三者都相同)产生三维坐标空间,你可以用公式定义该空间的关系,比如说x*y = z。如果它们满足给定的公式,则每个可能的坐标集(x0,y0,z0)都在关系中,否则它们不是。

关系数据库使用此概念以及一些额外要求。首先,最重要的是,关系的大小必须是有限的。上面给出的产品关系不满足该要求,因为有无限多的3元组满足公式。还有许多其他考虑因素与实际计算机上实际或有用的解决实际问题有关。

更好地思考问题的方法是考虑每种类型的持久性机制在哪些方面比另一种更好。当您有许多必须支持它们之间的关系(外键约束)的单独数据集(表)时,您已经认识到关系解决方案是有意义的,这几乎不可能通过键值存储实施。关系的另一个真正优势是它可以通过使用适当的索引来实现丰富的即席查询。这是数据库层实际理解它所代表的数据的结果。

键值商店拥有它自己的一系列优势。其中一个更重要的是键值存储扩展的方式。 memcachedcouchdbhadoop都使用键值存储,因此很容易在多个服务器上分发键值查找。键值存储运行良好的另一个方面是当键或值不透明时,例如当存储的项目被加密时,只能被其所有者读取。


要将这一点推向家庭,即使您不需要多个表,关系数据库也能正常运行,请考虑以下内容(非原创)

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来计算培根数为6的每个演员

答案 1 :(得分:2)

BerkeleyDB很好,也看看* DBM化身(例如GDBM)。但最大的问题是:你需要搜索什么?您是否需要按该网址,一系列网址或您列出的日期进行搜索?

还可以将记录组保存为本地文件系统中的简单文件,按日期或搜索条件分组,& c。

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

至于key / value thingy,你需要确保的是KEY本身已经很好地定义了你的查找。例如,如果您需要按日期按日期查找,而其他按标题查找,则需要维护“记录”行,然后可能需要2个或更多“索引”行来引用原始记录。您可以在键/值存储中建模几乎任何内容。

答案 2 :(得分:2)

我个人也会使用sqlite。它一直为我(以及我合作的其他人)工作过。当您的应用程序增长并且您突然想要做一些更复杂的事情时,您将不必重写。

另一方面,我在Python开发人员列表中看到过关于Berkely DB的各种评论,这些评论表明它并不精彩;你只能获得dict风格的访问权限(如果你想选择某些日期范围或标题而不是URL,该怎么办);它甚至不是Python 3的标准库集。

答案 3 :(得分:1)

MongoDB怎么样?我还没试过,但看起来很有趣。

答案 4 :(得分:1)

如果您只想使用单个字段来查找记录,那么简单的键值存储将是一个不错的选择。将该单个字段(或任何其他唯一ID)存储为您的密钥,将每个记录序列化为字符串(使用JSON或类似字符串),并将该字符串存储为值。 Berkeley DB无疑是键值商店的合理选择,但有很多选择可供选择: http://en.wikipedia.org/wiki/Dbm

如果您想通过多个字段查找记录,SQLite可能最容易用于开发目的。您将在SQL中编写查询,但您不必维护数据库服务器。所有的多功能机器都已经为您编写。

如果您真的想要避免SQL或从数据存储中挤出所有性能,,您需要多键访问,请在键值之上考虑一层额外的逻辑商店。通过序列化记录并将每个记录的“列”值插入其值包含记录的“主”键的附加键,可以在键值存储之上构建类似行的行为。 (您实际上将键值存储用作记录字典和索引字典以查找这些记录。)Google的App Engine就是这样做的。您可以自己执行此操作,也可以使用各种面向文档的数据库中的一种来为您执行此操作。对于一些有趣的阅读,尝试谷歌搜索“nosql”。 http://www.google.com/search?&q=nosql

答案 5 :(得分:0)

好的,所以你说只是存储数据..?你真的只需要一个DB来检索,查找,总结等等。因此,对于存储,只需使用简单的文本文件和追加行。如果需要,压缩数据,在字段之间使用delim - 几乎任何语言都能读取这些文件。如果您确实想要检索,那么请关注您的检索需求,按日期,按键,哪些键等。如果您想要简单的客户端,那么您需要简单的客户端数据库。 SQLite比BDB容易得多,但是看看像Sybase Advantage这样的东西(非常快速且对本地客户端而言是免费的,但不是开源的)或VistaDB或firebird ......但是所有这些都需要本地配置/设置/维护。如果您使用本地XML获取“相当大”的记录数量,则会为您提供一些不必要的文件大小......!