Database design NDB：按多个实体上的属性筛选

我来自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的情况下最好地做到这一点？一个示例查询将非常有帮助

使用与上述键的关联和将袜子/领带作为PromDate的重复结构属性之间的权衡是什么？具体来说，如果我们在PromDate中添加成吨的其他衣物（例如，数十万件），我担心尺寸限制（根据文档，为1MB）

---

基本上，我们应该如何在NDB中考虑这样的复杂查询？我们如何使它们快速、简单，最重要的是，能够在高数据量下进行扩展？

不幸的是，我相信您将需要几个查询来缩减所需的

PromDate

实例列表

这就是NoSQL：您越仔细地规范化您的模式，情况就越糟糕，因为您看到，没有连接

---

反规范化（有时使用结构化属性，有时更简单——例如只使用设计器名称代替设计器键，这样您就可以直接对其进行查询）会有所帮助，但是，它与关系数据库仍然是一个非常不同的世界（这就是为什么仍然提供关系数据库，例如Google Cloud SQL作为替代方案）.

您可以对数据进行反规范化，形成结构化属性，然后对其运行多个筛选器

从他们的样本中：

class Address(ndb.Model):
    type = ndb.StringProperty()  # E.g., 'home', 'work'
    street = ndb.StringProperty()
    city = ndb.StringProperty()

class Contact(ndb.Model):
    name = ndb.StringProperty()
    addresses = ndb.StructuredProperty(Address, repeated=True)

def query_contact_multiple_values_in_single_sub_entity():
    query = Contact.query(Contact.addresses == Address(city='San Francisco',
                                                       street='Spear St'))
    return query

---

阅读其他答案，例如，鉴于1MB大小限制和5k重复属性限制，StructuredProperty解决方案似乎肯定不起作用。因此，我想我的主要问题是如何执行粗体查询。不幸的是，我相信您需要几个查询来缩减所需的

PromDate

实例列表。这就是NoSQL：您越仔细地规范化您的模式，情况就越糟，因为您知道，没有连接！反规范化（有时使用结构化属性，有时更简单——例如只使用设计器名称代替设计器键，这样您就可以直接对其进行查询）会有所帮助，但是，它与关系数据库仍然是一个非常不同的世界（这就是为什么仍然提供关系数据库，例如Google Cloud SQL作为替代方案）.我想你是对的。如果你想提交答案，我很乐意接受。我认为这个例子可能对那些正在研究将关系模式转换为密钥存储的限制/问题的人有所帮助。