在Java中的谷歌应用程序引擎数据存储HRD，
我们不能直接使用query对象或GQL 进行联接和查询多个表
我只想知道我的想法是正确的方法还是不是
如果我们通过节点按照父子-长子的分层顺序建立索引
节点-密钥-IndexedProperty-设置
如果我们想收集所有子级的&孙子的。我们可以收集所有在层次过滤条件下匹配的密钥，并提供密钥的结果
在Memcache中，我们可以保存每个键并指向DB实体，如果缓存在一个查询中没有使用一组键，我们可以从DB中获取所有记录。
Pros
1） 快速检索-谷歌建议使用按键获取实体。
2） 单个事务足以收集多个表数据。
3） Memcache和Persistent Datastore将代表相同的形式。
4） 它将只扫描与组类似的用户或父节点的相关数据。
Cons
1） 数据库大小的元数据会增加，因此数据库大小会增加。
2） 如果单亲的索引需要超过1MB，那么我们必须在DB中拆分并另存为blob。
这种结构是否是一种好方法。
如果我们在层次结构中有更深的层次，这将解决运行大量查询操作以收集依赖于父项的所有项的问题。
如果是多名父母——收集所有索引并获取与查询相关的键。使用密钥列表收集单个事务中的所有数据。
如果有人发现了更多的优点或缺点，请添加它们并证明这种方法是否正确。
非常感谢
Krishnan
这里有很多事情需要思考：
数据存储是而不是关系数据库。您绝对不应该从表和联接的角度来处理您的数据存储。这将导致一个混乱的，很可能是低效的设置。
您似乎正在尝试重新组织对数据存储的使用，以提供对数据的完整事务性和强一致性使用。数据存储无法以本机方式提供这一功能的原因是，在提供高可用性的同时提供这些保证的效率太低。
使用数据存储，您希望能够提供每秒向不同实体进行多次（数千、数十万、数百万等）写入的能力。数据存储提供实体组概念的原因是它允许开发人员指定特定的一致性范围。
考虑一个todo跟踪服务示例。您可以定义一个User和一个Todo类型。你不想为所有Todo提供强大的一致性，因为每次用户添加新的笔记时，底层系统都必须确保它与所有其他写笔记的用户进行交易。另一方面，使用实体组，您可以说单个用户代表您的一致性单元。这意味着，当用户编写新笔记时，必须通过对该用户笔记的任何其他修改来进行事务更新。这是一个更好的一致性单元，因为随着服务扩展到更多的用户，它们不会相互冲突。
您正在讨论创建和管理自己的索引。从效率的角度来看，你几乎肯定不想这么做。此外，您必须非常小心，因为似乎要对表示表的单个实体/实体范围进行大量写入。这是一种已知的数据存储反模式。
数据存储的难点之一是，每个项目可能有非常不同的需求，因此数据布局也不同。如何构建数据绝对不是一刀切的，但这里有一些资源：
- 写入数据存储时实际发生的情况
- 数据存储如何存储数据
- 数据存储实体关系建模
- 数据存储事务隔离