代码之家 › 专栏 › 技术社区 › Xeoncross

关键价值商店有ORM(OKM)吗?

nosql orm database

Xeoncross · 技术社区 · 14 年前

创建对象关系映射器是为了帮助应用程序(从对象的角度考虑)像处理其他类/对象一样,以更友好的方式处理存储的数据。

four requests:
user:id
user:id:name
user:id:email
user:id:created

vs one request:
user = [id => ..., name => ..., email => ...]

另外,你必须跟踪“列表”(post有很多评论),因为你没有太多的表或外键。

INSERT INTO user_groups (user_id, group_id) VALUES (23, 54)

vs

usergroups:user_id = {54,108,32,..}
groupsuser:group_id = {23,12,645,..}

还有很多附加逻辑的例子,应用程序需要复制普通关系数据库使用的一些基本特性。所有这些原因使得OKM的概念听起来像是一个鞋印。

4 回复 | 直到 14 年前

Bob Aman 14 年前

鲁比的 DataMapper project是一个ORM,可以通过适配器与键值存储进行愉快的对话。

Redis 和 MongoDB Dubious framework 因为Google App Engine采用了与Data Mapper非常相似的方法,使数据存储对应用程序可用。

因此,使用键值存储进行ORM是非常有可能的。ORM只需要避免假设SQL是它的主要词汇表。

Tom Clarkson 14 年前

除了生成样板数据访问代码之外,ORM的主要目的之一是抽象平台之间的差异。根据我的经验,切换平台的能力一直都是纯理论性的,而且这种最低公分母的方法对于NoSQL根本不起作用,因为该平台通常是专门为其他平台上不存在的功能而选择的。您的示例仅用于最简单的键值存储-根据您的平台,您很可能有一些有用的附加命令,因此第一个示例可以是

MGET user:id:name user:id:email。。。(multiget-在一次调用中获取任意数量的键)

获取用户:id:*(密钥通配符)

HGETALL user:id(redis hash-获取用户的所有子键)

您还可以将用户对象存储在序列化的表单中—与关系数据库不同,这不会中断所有查询。

如果您的平台没有内置的支持,那么使用列表就不太好了—我喜欢使用redis的原因之一是本地列表/集支持—但是除了可能需要锁之外,这并不比从sql中获取列表差。

我发现从索引而不是关系的角度来思考是有帮助的——在设置数据访问代码时,决定需要查询哪些字段,并在编写这些字段时添加适当的索引记录。

Jeremiah Peschka 14 年前

ORMs不能很好地映射到键值存储的无模式特性。也就是说,如果你用的是Riak和Ruby,你可以看看 Ripple

如果您正在研究MongoDB(更多的是文档存储,而不是k/v存储),有很多 drivers

James Anderson 14 年前

UNIVERSE db是Pick的后代,它允许您存储给定密钥的键值对列表。然而,这是一个非常古老的技术主义和世界逃离这些数据库很久以前。

可以在具有三列表的SQL数据库中实现此功能

  CREATE TABLE ATTRS ( KEYVAL VARCHAR(32),
                       ATTRNAME VARCHAR(32),
                       ATTRVAR  VARCHAR(1024)
                     )

尽管大多数dba都会使用非常厚的Codd和Date精装版(如果您建议这样做的话),但实际上这是打包应用程序中非常常见的一种模式,允许您向系统添加特定于站点的属性。

给普拉普拉普拉斯·里赫德·史泰尔曼关于LISP的评论。 “任何功能合理的数据存储系统最终都会实现自己版本的RDBMS。”