Question

在用户既拥有系统创建的物品又拥有自己的物品的待办事项列表中，您将如何存储这些物品？

待办事项列表可以包含多种项目。与用户创建的项目一样，可以修改和删除系统创建的项目。最初从配置中提取系统创建项目的标题和描述文本是有区别的。许多用户可以具有相同的系统创建的项目。例如。如果两个用户想要在他们的房屋中粉刷房间，他们都会得到“购买粉刷”物品。

选项1

将完整的系统创建的项目（包括标题和文本）与用户创建的项目一起保存。

优点：：由于项目属于用户且不依赖于中央项目配置，因此可以灵活地进行用户修改。

缺点：大量的冗余，因为将有很多用户都具有相同的项目。

选项2

使用用户创建的项目保存对系统创建的项目的配置引用。

优点：系统修改的灵活性，因为如果我们要说“购买X品牌油漆”而不是“购买油漆”，则使用此项目的所有用户都很容易反映出更改。

>

缺点：即使该项目与新的待办事项列表不再相关，系统创建的项目也必须在配置中永久保留，否则用户的引用将被破坏。

谢谢！

Answer 1

我最初的想法是-您的要求是什么？您的用户流和项目路线图可能包含信息以告知您的设计。

从您的问题“系统创建的项目可以像用户创建的项目一样进行修改和删除”：

您还没有提到仅需要对系统创建的待办事项进行操作的情况。但是在这种情况下，您可以包括创建者元数据。

Answer 2

我认为这里的关键是您是否需要修改“系统待办事项”，并且该更改要反映在所有“用户待办事项”中...
如果这是一个要求（对我来说听起来很明智），则您唯一的选择是选项2-选项1的真正缺点是，一旦您将“系统待办事项”复制为“用户待办事项”，就无法再知道它们是否相关...

我将选择一个类似的模型，其中包含2个实体/表：

ToDoTemplate
  Integer id
  String name
  String description

ToDoItem
  Integer id
  ToDoTemplate template
  Boolean completed = false
  ?String name = null
  ?String description = null

创建ToDoItem时，您将基于ToDoTemplate（可能是空白模板）创建它，并将name和description设置为{ {1}}，重用模板名称/描述...仅当用户修改自己的null时，才是存储该值的时间...即

ToDoItem

这是最灵活的方法，在许多情况下也是唯一有效的方法。请注意您提到的缺点：

缺点：即使系统不再与新的任务列表相关，系统创建的项目也必须在配置中永久保留，否则用户的引用将被破坏。

这实际上不是一个缺点-只要有一个String getName() { return this.name != null ? this.name : this.template.name; }使用给定的ToDoItem，模板仍然有意义，当然没有理由删除它...