Как хранить созданные в системе элементы списка дел?

Question

В списке дел, где пользователи имеют как созданные системой элементы, так и свои собственные, как бы вы хранили эти элементы?

В списке дел может быть множество предметов. Созданные системой элементы могут быть изменены и удалены так же, как созданные пользователем элементы. Разница заключается в том, что названия и текст описания для созданных системой элементов изначально извлекаются из конфигурации. Многие пользователи могут иметь одинаковые элементы, созданные системой. Например. если два пользователя захотят покрасить комнаты в своих домах, они оба получат предметы «купить краску».

Вариант 1

Сохраните все созданные системой элементы (включая заголовок и текст) вместе с созданными пользователем элементами.

Плюсы: Гибкость для пользовательских модификаций, поскольку элементы принадлежат пользователю и не зависят от конфигурации центрального элемента.

Минусы: Много избыточности, потому что будет много пользователей с одинаковыми предметами.

Вариант 2

Сохранение ссылок на конфигурацию для элементов, созданных системой, с элементами, созданными пользователем.

Плюсы: Гибкость для системных модификаций, поскольку, если мы хотим сказать «купить краску X-бренда» вместо «купить краску», изменение легко отражается для всех пользователей с этим элементом.

Минусы: Созданные системой элементы должны постоянно сохраняться в конфигурации, даже если элемент больше не актуален для новых списков дел, поскольку в противном случае ссылка пользователя будет нарушена.

Другие варианты?

Спасибо!

Answer 1

Я думаю, что ключевой момент здесь заключается в том, нужно ли вам иметь возможность изменять «системные задачи», и это изменение должно быть отражено во всех «пользовательских задачах» ...
Если это требование (звучит разумнодля меня), ваш единственный вариант - это вариант 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 как null, повторно используя имя / описание шаблона ... Только если пользователь изменяет свое собственное ToDoItem, это когда вы сохраняете это значение ...то есть

String getName() {
  return this.name != null ? this.name : this.template.name;
}

Это наиболее гибкий из подходов и единственно допустимый во многих ситуациях ... Обратите внимание на то, что вы упомянули:

Минусы: созданные системой элементыдолжны сохраняться навсегда в конфигурации, даже если элемент больше не актуален для новых списков дел, потому чтоВ противном случае ссылка пользователя будет нарушена.

Это на самом деле не мошенничество - пока есть один ToDoItem, который использует данный ToDoTemplate, шаблон все еще актуален , и, конечно, нет никаких причинубрать это ...

Answer 2

Моя первоначальная мысль - каково ваше требование? Ваши пользовательские потоки и дорожная карта проекта могут содержать информацию для информирования вашего дизайна.

От вашего вопроса "созданные системой элементы могут быть изменены и удалены так же, как созданные пользователем элементы":

• Это означает, что у вас должен быть способ отслеживать изменения в ваших «созданных системой» шаблонах для каждого пользователя или преобразовывать их в «созданные пользователем» сообщения при их редактировании.
  • Это сложнее, чем кажется
• Кажется, гораздо проще создавать сообщения из системных шаблонов, чем обычные сообщения.
• Немного лишнего хранилища не сломает банк

Вы не упомянули ни одного случая, когда вам нужно было бы работать только над созданными системой задачами. Но в этом случае вы можете включить созданные метаданными.