代码之家  ›  专栏  ›  技术社区  ›  Derek Dahmer

键的ListProperty与多对多应用程序内引擎

  •  11
  • Derek Dahmer  · 技术社区  · 17 年前

    作为一个假设的例子,我有一个模型todoitem和一个模型todolist。todoist有一个有序的todoitem列表,并且任何一个todoitem都可以属于任意数量的todolist(多对多)。除了todoist中todoitem的顺序之外,不需要存储有关它们之间关系的任何其他信息。在数据存储中表示这一点的最佳方法是什么?

    有两种方法可以实现这一点-给todolist类一个db.key的listproperty,它将引用todoitem的:

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

    或者制作一个也包含排序信息的列表项模型:

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

    我以后肯定会通过取消模型的规格化来优化这一点,但是预优化,任何一种表示都比另一种表示有优势吗?

    3 回复  |  直到 16 年前
        1
  •  10
  •   Nick Johnson    17 年前

    这取决于几个因素:

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

    如果您需要额外的信息,或者关联中有许多元素,或者只需要检索其中的一些元素,那么关系实体可能是更好的选择。在其他情况下,列表既简单又快速。在todo列表的情况下,我会说一个键列表绝对是最好的方法。

        2
  •  1
  •   Alex Martelli    17 年前

    除了在关系上下文中推动规范化(当然,在关系上下文中是非常明智的!)对于我来说,独立的托多利斯主义“关系类”似乎有点过分了,而且在解决问题的一个原因和编码问题的方式上有点“呆板”。然而,从优化的角度来看,它肯定会使查找项目所在的所有列表变得更容易。

        3
  •  0
  •   Adam Crossland    16 年前

    考虑到todolistem可以属于多个todolist,我担心对于该项所属的每个列表,使用单个order属性是有效的。我想这个项目需要为它所属的每一个列表下一个订单。