我需要为类似Amazon S3的应用程序设计数据模型。让我们将问题简化为3个关键概念 - 用户，存储桶和对象。有很多方法可以设计这个模型 - 我将列出两个。
三种 - 用户，存储桶和对象。每个对象都有一个Bucket作为其父级。每个Bucket都有一个User作为其父级。用户是根。
动态种类 - 用户存储在用户类型中，存储桶存储在存储桶类型中 - 与＃1相同。但是，存储桶中的对象存储在名为“＆lt; BucketID＆gt; _Object”的动态类型中。桶和对象实体之间不再存在父/子关系。此关系由对象类型的名称建立。
＃1当然是更直观和传统的模型。人们可以争辩说＃2是激进的，而其他人可能会说荒谬。
为什么我在考虑＃2？ - 在我的应用程序中，对象上定义的属性可能因桶而异。这些属性由用户在存储桶创建时指定。此外，对象上的所有属性都需要是可查询的。每个桶的动态对象类型允许我支持这些要求。此外，因为我的对象类型现在是根类，我不再需要应用祖先过滤器，这意味着我可以免费获得每个对象属性的索引。在模型＃1中，我被迫应用祖先过滤器，这意味着我需要为我要查询的每个属性都有一个自定义索引。
我为复杂的解释道歉。如果不清楚，我会更好。
我的问题是 - ＃2是一个完全离谱的模特？对于＃2，我的种类可能会遇到成千上万的。这可以吗？我知道自定义索引的数量有限制。但我不是在动态类型上创建自定义索引，而是仅依赖于自动索引。
谢谢， Keyur
答案 0 :(得分：4)
两者都存在问题。 ＃1基本上没问题，除了使用引用属性而不是祖先，并使你的Object类型成为Expando。
来自用户和来自桶的对象的桶的问题是，这会强制用户创建的每个桶和对象生活在同一个entity group中。这限制了性能和可伸缩性，因为所有单个用户的数据都必须存储在同一数据存储节点上。当您需要在同一事务中操作多个实体时，实体组很有用。如果您只需要为所有权建模，请使用ReferenceProperty。
在我的 应用程序，定义的属性 对象可能因桶而异 桶。指定了这些属性 用户在桶创建时。 此外，对象上的所有属性都需要 是可查询的。
Expando给你这两个。您的属性可以即时定义，并且它们会自动编入索引。
没有什么要求同一类型的两个实体具有相同的属性集。种类只是名字;他们没有定义或实施任何类型的架构。在飞行中创建一堆它们并不会给你买任何东西。