使用重复属性的唯一好处是可以避免最终的一致性问题：每当您阅读
UserActivity或
CompanyActivity实体时，您就会知道您已获得所有活动的
完整 列表。使用第一种方法时，您必须进行查询才能获得该列表，并且该列表可能会错过最近的活动，因为相应的查询索引可能尚未更新以反映它们。
但是，除了您提到的潜在争用问题之外，对于重复属性方法还需要考虑另一个缺点：随着越来越多的活动添加到列表中，这些实体的大小将逐渐增加，这意味着：
- 逐渐变慢
get()
/put()
次，因此逐渐降低整体应用程序性能 - 存在达到最大数据存储实体大小（约1MB，请参见Limits）的风险，这将需要其他逻辑才能将列表拆分到多个实体中
特别是第三种方法还需要一种获取每个用户活动报告的简单方法。
我坚持第一种方法，这是最灵活，可扩展的方法，缺点很小：
- 最终的一致性问题是恕我直言，这不是一个阻碍因素（可能有减少其影响的方法）
- 额外的存储空间（对于存储在每个
Activity
实体中的用户/公司ID属性，以及由于实体数量较多而导致的更大索引）是恕我直言的（很便宜）。
