我一直在编写App Engine应用程序，最近开始对App Engine的数据扩展时有一些担忧。
我的应用程序包含员工数据。 Employee实体拥有许多属性，如名字，姓氏，生日，地址，电话，手机，参考人员，教育背景，培训历史，收入数据等。未来总物业最多可达100个。
起初，我认为我不应该将所有属性打包在一个作为Employee实体的实体中，因为每当我想要放置或更新几个属性时，我必须获取实体中的所有属性实体，所以我以一对一的关系方式将实体分解成许多实体，并将用户界面变为选项卡，联系信息选项卡，教育背景选项卡，收入选项卡等。当用户单击选项卡时，将从该特定实体加载数据，并自动保存先前关闭选项卡上的数据。为了性能和成本效率，我将一个大型实体划分为许多小型一对一关系实体。我这样做也是为了提高寻呼效率，只需要为员工列表页面提供最小属性编号的小实体。
在阅读App Engine定价模型后，它根据写入和阅读每个实体的时间收取成本，这意味着我设计实体的方式将增加写入和阅读次数。我认为我的设计具有成本效益并且性能更好。每次获得实体时，我使用较少的CPU和带宽，因为我不需要一次在同一页面上显示所有属性。
或者我应该将实体压缩成一个或几个实体，以提高我的应用程序性能并降低成本。对于分页功能，我可以创建一个特定用途的实体来手动处理分页。
答案 0 :(得分：3)
如果您的Employee实体具有许多索引属性，那么您的方法是正确的。每次更新实体时，都会产生每个索引属性的写入成本。因此，将实体拆分为较小的部分将显着降低在实体生命周期内的写入成本。换句话说，第一次写入所有这些数据的初始成本可能略高，但每次后续更新都会大大降低。
类似的逻辑适用于读取。只有当您的用户点击每个员工的每个选项卡时，多个实体才会稍贵一些，这种可能性极小。大多数情况下，他们会在需要读取数据或进行更改时转到特定选项卡。
注意：我还必须注意，除非你有成千上万的用户，否则这些方法之间的差异可能不值得花时间。