11

作为一个假设的例子，我有一个模型 TodoItem 和一个模型 TodoList。一个 TodoList 有一个 TodoItem 的有序列表，任何一个 TodoItem 都可以属于任意数量的 TodoList（多对多）。除了 TodoList 中 TodoItem 的顺序之外，不需要存储有关它们关系的其他信息。在数据存储中表示这一点的最佳方式是什么？

有两种方法可以实现这一点 - 给 TodoList 类一个 db.Key 的 ListProperty，它将引用 TodoItem：

class TodoList(db.Model):
  items = db.ListProperty(db.Key)

或制作一个包含订购信息的 ListItem 模型：

class TodoListItem(db.Model):
  item = db.ReferenceProperty(TodoItem)
  list = db.ReferenceProperty(TodoList)
  order = db.IntegerProperty()

稍后我肯定会通过对模型进行非规范化来优化这一点，但是在优化前，任何一种表示都比另一种表示有优势吗？

4

3 回答 3

10

这取决于几个因素：

  • 您是否需要存储有关关系本身的信息，而不是它的顺序？例如，订单和产品之间的多：多需要存储每个产品的数量。
  • 您是否需要将关系一侧的一千多个项目与“较小”基数相关联（例如，>1000 个待办事项，或一个项目的>1000 个列表）？
  • 您通常想要一次检索所有关联的项目，还是想要更有选择性？

如果你需要额外的信息，或者你的关联中有很多元素，或者只需要检索其中的几个，关系实体可能是一个更好的选择。在其他情况下，列表可以更容易和更快。对于待办事项列表，我会说键列表绝对是最好的方法。

于 2009-09-04T09:14:28.760 回答
1

除了在推动规范化的关系上下文中（当然，在关系情况下非常可取！）单独的 TodoListItem “关系类”对我来说似乎有点矫枉过正，而且就方式而言有点“生硬”关于问题的原因与编码方式。但是，在优化方面，它肯定会使查找项目所在的所有列表变得更容易。

于 2009-09-04T02:01:13.377 回答
0

鉴于 TodoListItem 可以属于多个 TodoList，我会担心拥有一个适用于该项目所属的每个列表的单个 order 属性是有效的。我认为该项目需要为它所属的每个列表提供一个订单。

于 2009-12-22T19:58:29.627 回答