Question

我的应用程序具有以下模型：

class Employee:
  name = attr.ib(str)
  department = attr.ib(int)
  organization_unit = attr.ib(int)
  pay_class = attr.ib(int)
  cost_center = attr.ib(int)

它可以正常工作，但是我想将我的应用程序重构为更多的微内核（插件）模式，其中有一个核心的Employee模型，可能仅具有名称，而插件可以添加其他属性。我想也许一种可能的解决方案可能是：

class Employee:
  name = attr.ib(str)
  labels = attr.ib(list)

员工可能看起来像这样：

Employee(
   name='John Doe'
   labels=['department:123',
           'organization_unit:456',
           'pay_class:789',
           'cost_center:012']
)

也许另一种解决方案是只为每个“标签”创建一个实体，并以核心雇员为祖先键。此解决方案的一个问题是，当前写入实体组的速度限制为每秒1次，尽管一旦Google将现有数据存储升级到新的“数据存储模式下的Cloud Firestore”，该限制就会消失（希望很快）：

https://cloud.google.com/datastore/docs/firestore-or-datastore#in_native_mode

我想在list属性和祖先键方法之间进行应用程序级的权衡是，list方法将插件与内核更紧密地耦合在一起，而祖先键的数据方案则更不耦合（尽管不是全部）。

在性能还是其他方面我还有其他需要考虑的权衡吗？

Answer 1

我个人出于多种原因会使用多个属性，但是可以混合所有这些解决方案，以实现应用程序所需的不同程度的灵活性。主要的权衡是

a）您无法在数据存储中进行联接，因此将相关数据存储在多个实体中将阻止使用复杂的where子句进行查询（祖先键方法） b）如果将数字和日期字段作为标签（列表属性方法），则无法进行范围查询 c）如果您为标签字段建立索引并且实际上只需要索引一小部分标签，则索引可能会很大且昂贵

所以，考虑将这三个因素混合在一起的一种方法是

a）对于静态数据和应用程序逻辑，请使用多个属性。 b）对于将不用于查询的动态数据，可以使用标签列表。 c）对于插件需要查询但不需要与静态数据连接的可插拔数据，您可以创建另一个实体，该实体再次使用a）和b），因此该插件将所有相关数据存储在一起。

在Cloud Datastore中，列表属性与多个属性与祖先键之间的权衡是什么？

1 个答案: