【发布时间】:2014-11-28 14:59:41
【问题描述】:
我来自 SQL 背景,我想知道如何在 NDB 中过滤相当于 SQL 中的许多连接,以及如何使这些查询扩展。举个例子:
class PromDate(ndb.Model):
user_id = ndb.StringProperty(required=True) # user id
age = ndb.IntegerProperty()
class DesignerBrand(ndb.Model):
name = ndb.StringProperty()
class Socks(ndb.Model):
owner = ndb.KeyProperty(kind=PromDate, required=True) # reference to PromDate
designer = ndb.KeyProperty(kind=DesignerBrand, required=True) # reference to DesignerBrand
color = ndb.StringProperty()
do_they_smell = ndb.BooleanProperty()
class Tie(ndb.Model):
owner = ndb.KeyProperty(kind=PromDate, required=True) # reference to PromDate
designer = ndb.KeyProperty(kind=DesignerBrand, required=True) # reference to DesignerBrand
color = ndb.StringProperty()
如果我们想找到一个 21 岁以上的 PromDate 拥有蓝色 Calvin Klein 或 Target 无气味袜子和红色领带,我们如何在不使用 StructuredProperties 的情况下最好地做到这一点? 示例查询会非常有帮助。
在使用与上述键的关联和将 Socks/Tie 作为 PromDate 的重复 StructuredProperty 之间的权衡是什么?具体来说,如果我们在 PromDate 中添加大量其他衣物(例如,数十万件),我会担心大小限制(根据文档,为 1MB)。
基本上,我们应该如何在 NDB 中考虑这样的复杂查询?我们如何让它们保持快速和简单 - 最重要的是,在大量数据下可扩展?
【问题讨论】:
-
阅读其他答案,如 stackoverflow.com/questions/11748695/… ,鉴于 1MB 大小限制和 5k 重复属性限制,StructuredProperty 解决方案似乎绝对行不通。所以我想我的主要问题是如何以粗体执行查询。
-
不幸的是,我相信您需要多次查询才能缩减所需的
PromDate实例列表。这就是你的 NoSQL:你越仔细地规范你的模式,越糟糕,因为,你看,没有连接!反规范化(有时使用结构化属性,有时更简单——例如,只需使用设计器名称代替设计器键,以便您可以直接查询它)会有所帮助,但是,它仍然是一个非常不同的世界关系数据库(这就是为什么仍然提供关系数据库,例如谷歌云 SQL,作为替代品的原因)。 -
我认为你是对的。如果您想将其作为答案提交,我很乐意接受。我认为这个示例可能对正在调查将关系模式转换为密钥存储的限制/问题的人有所帮助。
-
完成,现在是答案。
标签: database-design app-engine-ndb google-cloud-datastore