我对应用程序引擎数据存储区相当陌生，但我知道它的设计更像是哈希表而不是数据库表。这让我认为“一般来说”最好有更少的行(实体)和更多的列(对象属性)。
也就是说，您可以使用属性 color 和 count 创建一个 Car 对象，也可以使用属性 redCount< 创建它、blueCount、greenCount，假设您知道所有颜色(尺寸)。如果您要存储这些对象的实例，您将拥有三个或一个:
对于每种颜色和数量，保存新实体:
“红色”，3
“蓝色”，8
“绿色”，4
或者保存一个实体，其中包含每种可能颜色的属性:3, 8, 4
显然后一种方法存在一些设计挑战，但想知道摆脱关系思维的建议是什么？似乎数据存储对数百个“列”/属性非常满意。
最佳答案
努力摆脱关系思维，做得很好。摆脱行/表思维是件好事。
至少在编程方面，更接近的近似是将实体视为远程存储的数据结构或类实例。这些实体具有属性。索引与实体分开，索引本质上存储与某些属性条件匹配的实体列表。
当您写入实体时，数据存储区会更新内存/存储中的该实例，然后更新所有索引。
当您执行查询时，您实际上会遍历索引列表之一。
这应该为您提供一个思考数据存储的基本框架。
当您设计数据存储时，通常必须考虑成本，并在较小程度上考虑性能。在写入方面，您希望尽量减少索引的数量。在读取方面，您希望最大程度地减少正在读取的实体数量，因此为红色、蓝色、绿色设置单独的实体的想法可能是一个坏主意，如果您不断需要读回数字，则读取成本会增加两倍红色/蓝色/绿色汽车。可能存在一些非常模糊的极端情况，这才有意义。
您的设计考虑因素通常应遵循以下原则:
- 我需要执行哪些类型的查询？
- 如何构建数据以使这些查询易于执行(因为 GAE 查询功能有限)？如果我以某种方式复制数据，查询会更容易吗？我是否能够自己维护这些重复的数据？
- 如何最大限度地减少更新实体时需要更新的索引数量？
- 是否有任何特殊情况，我必须具有完全一致性，因此需要调整结构以便可以进行一致的查询？
- 是否有任何我需要注意的写入性能情况。
在不确切知道您要进行哪种查询的情况下，这个答案可能不正确，但它应该说明您可能会如何看待这个问题。
我假设您有一个应用程序，人们可以在其中注册他们的汽车，并且您有一些仪表板可以轮询数据存储并显示每种颜色的汽车数量，这是具有带有颜色的 Car 类的传统机制，计数属性仍然这是有道理的，因为它最大限度地减少了索引属性的数量，从而降低了写入成本。
这是一个有点奇怪的例子，因为我无法判断您是否只想有一个实体来跟踪您的计数(在这种情况下您甚至不需要进行查询，您可以获取该计数)，或者如果您有多个可以获取并求和的计数实体。
如果用户更新修改了同一实体，您可能会遇到性能问题，您应该阅读以下内容:https://developers.google.com/appengine/articles/sharding_counters
关于java - 设计应用程序引擎数据存储区时，重复 "rows"还是 "columns"更好？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19043534/