0

我正在构建一个具有多对多关系的应用程序；实体“图片”的项目可以链接到任意数量的画廊（“画廊”）。当然，画廊可以容纳任意数量的图片。

因此，按照此处的 Google 建议，我将在“图片”处使用一个包含“画廊”外键的列表。这是 BigTable 方法。

（旧式关系数据库方法是在“图片”和“画廊”之间有一个表/实体。）

这是我的问题：存储密钥时，我应该在“图片”上选择“StringListProperty”还是“ListProperty（db.Key）”效果更好？

我看到StringList的一个原因是，我还可以存储除键之外的其他值，但另一方面，无论如何这都是肮脏的风格。但我也很确定谷歌建议不要在一个实体上使用一个以上的列表，因为索引会爆炸。所以这会让我成为一个后门。

至于“ Key ”类型的ListProperty，如果值实际上是 Key，则有一点是自动验证。

由于将字符串转换为键非常容易，反之亦然，我看不出有任何理由让其中一种 List 类型更喜欢这里。

当谈到性能问题时，我不知道如何测试它——但看起来这将是这个决定的主要因素。

好奇你的输入。尤其是如果有人对此进行了测试，或者会非常友善地去做。

干杯，//汉内斯

4

2 回答 2

0

使用 db.ListProperty(db.Key)，这将使数据获取比字符串更容易。如果 Gallery 模型具有属性 pic_list，其类型为 db.ListProperty(db.Key)，其中包含图片的键列表entity.. 假设 Picture 是您的实体的名称.. 然后 Picture.get(//GalleryObject//.pic_list) 将获取所有图片实体..

于 2011-01-20T04:40:41.070 回答
0

db.ListProperty(db.Key)如果您打算存储键列表，请使用 a 。它们将以二进制表示形式存储，比您在字符串列表中使用的字符串表示形式更紧凑。

您说得对，将键与列表中的其他对象混合是很麻烦的。在一个实体中有多个列表是可以的，只要您不在同一个自定义索引中索引多个列表 - 这就是导致索引爆炸的原因。

于 2011-01-12T23:03:17.677 回答