我看到两种可能性: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的演员。