如何在 App Engine 中建模多对多关系？
我有一个关于如何在 App Engine 中建模多对多关系的问题：
Blogentry 可以有许多标签，一个标签可以应用于许多博客条目。
我看到了几个场景：
使用一组字符串作为博客条目上的属性。
- 这使我可以使用标签轻松查询条目
- 这不允许我获取所有标签及其权重（它们适用于多少个条目）
在条目和标签类（键集）之间使用无主关系对于 Entry 类中的标签，反之亦然）
- 这允许我获取所有标签及其权重
- 这维护起来要复杂得多
- Set 属性是延迟加载的，还是每次都会获取对象的整个图？ （获取一个Entry，即获取多个Tags，每个Tags依次获取多个Entries）
使用1.但单独维护标签及其权重的数据
- 这在标签数据和条目中的标签之间存在同步问题
任何输入和指针将不胜感激。我认为这是一个很常见的场景，但我还没有看到任何好的解决方案。
I have a question regarding how to model a many-to-many relationship in App Engine:
A Blogentry can have many tags, a tag can apply to many blog entries.
I see a couple of scenarios:
Use a Set of Strings as an attribute on the blog entry.
- This allows me to easily query for an entry using a tag
- This does not allow me to fetch all tags and their weights (how many entries they apply to)
Use an unowned relationship between an Entry and a Tag class (Set of keys for Tags in Entry class and vise versa)
- This allows me to fetch all tags and their weights
- This is much more comples to maintain
- Are Set attributes lazyloaded, or would I fetch the entire graph of object every time? (Fetch an Entry, which fetches a number of Tags, each in turn fetching a number of Entries)
use 1. but maintain data on tags and their weights seperately
- This has synchronisation issues between the Tag data and the tags in the Entries
Any input and pointers would be appreciated. I think this is a quite common scenario but I haven't seen any good solutions yet.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
与许多其他数据库管理系统一样，App Engine Datastore 本身并不支持多对多关系，但可以通过“连接表”来解决。但是，由于 App Engine 的查询语言不支持联接，因此在您的应用程序中使用这将非常痛苦。 Google 的 BigTable 架构实际上不鼓励这样做，因为分布式连接效率不高。
所以，我建议遵循“保持简单愚蠢”的规则；使用最简单有效的方法。 “Blogentry”对象中的字符串列表听起来相当健壮。即使它很容易出现竞争条件（人们并行进行更新，覆盖彼此的更改），但是有多少人编辑同一篇博客文章？
Like many other database management systems, many-to-many relationships are not natively supported in App Engine Datastore, but could be solved through a "junction table". However, since App Engine's query language does not support joins, this will be very painful to use in your application. Google's BigTable architecture in fact discourages this, because distributed joins are not efficient.
So, I suggest going with the "keep it simple stupid" rule; use the simplest thing that works. A list of strings in a "Blogentry" object sounds fairly robust. Even if it's prone to race conditions (people making updates in parallel, overwriting each other's changes), but how many people do you have editing the same blog post anyway?
我决定采用选项 3，维护一个单独的标签列表及其权重。
这似乎工作正常，尽管插入/更新代码有点混乱。
I decided to go with option 3., to maintain a seperate list of tags with their weights.
This seems to work ok, although the insert/update code is a bit cluttered.