Я уже читал thesequestions, но ответы либо неактуальны, либо неудовлетворительны.Дизайн базы данных для хранения контрольных списков и результатов
У меня есть список контрольных перечней, которые используются в качестве руководства для часто повторяющихся процедур. Контрольные списки постепенно меняются с течением времени, поскольку каждая процедура уточняется и улучшается.
Что я хочу сделать, так это хранить несколько отдельных контрольных списков, каждая из которых содержит произвольное упорядоченное количество Заданий. Пользователи системы смогут создать новый экземпляр контрольного списка и пометить «Задачи», поскольку они идут по данному экземпляру. Кроме того, мне нужно архивировать отдельные экземпляры каждого контрольного списка для ведения исторической записи, поэтому я могу вернуться и посмотреть, что было выполнено (в каком порядке, кем и т. Д.) В данном списке. (Для простоты я исключил эти «мета» поля ниже.) Я также хотел бы иметь возможность изменять Задачи в каждом контрольном списке с течением времени, не повреждая исторические экземпляры. другими словами, эти контрольные списки служат в качестве «шаблонов», из которых создаются и используются новые экземпляры.
Это представляет интересную проблему с дизайном базы данных, потому что вы не можете просто связать записи результатов с идентификатором записи задачи, это экземпляр. Например, следующая схема будет не работать, если вы хотите, чтобы иметь возможность изменить текст в каждой записи задач для улучшения Контрольных списков, сохраняя при этом точные результаты:
Checklists
int(11) id
varchar(255) title // Text title of Checklist. I.e: "Household Chores"
Tasks
int(11) id
int(11) checklist_id // Which Checklist this Task belongs to.
int(11) order_in_list // Sort order for Tasks within a Checklist.
varchar(255) text // Text of the Task. I.e: "Take out garbage".
Results
int(11) id
int(11) instance_id // Groups a set of tasks into a historical Checklist instance.
int(11) task_id // Which Task this row is an instance of. Pull the text and order from here.
tinyint(1) checked // Whether the given instance has been completed or not.
Чтобы использовать Cake просторечие:
Контрольный список HasMany Задачи
Целевая BelongsTo Контрольный список
Целевая HasMany Результаты
результате BelongsTo Задачи
Небольшое изменение было бы создать полную копию каждой задачи в результатах. Это позволяет нам сохранять исторические «наборы» Задач, сгруппированных экземпляром instance_id, чтобы представлять один экземпляр контрольного списка, включая заполненные биты.
Results
int(11) id
int(11) checklist_id
int(11) order_in_list
varchar(255) text // Store the full text of the Task in each result instance!?
int(11) instance_id
tinyint(1) checked
В этом случае: (! < не достаточно, чтобы описать отношения)
Перечень HasMany Задачи
Контрольный HasMany Результаты
Задача BelongsTo Контрольный
Результат BelongsTo Контрольный
На первый взгляд, это кажется расточительным, чтобы полностью скопировать текст и порядок выполнения каждой задачи, но я не могу придумать с хорошей альтернативой, сохраняющий текст исторических примеров контрольных списков.
В настоящее время я считаю, что реляционная БД не может быть лучшим решением для этой проблемы, но у меня ограниченный опыт работы с такими документами, как Mongo или Couch. Являются ли они лучшим механизмом хранения исторических данных контрольных списков? Это, по-видимому, имеет преимущество в логической группировке всех данных для контрольного списка или экземпляра в единую запись документа.
Мысли?
Есть ли лучший формат хранения? Что-то более похожее на wiki, может быть, где история изменений поддерживается для каждого контрольного списка, а группа ответов на данный контрольный список хранится в ссылке на конкретный номер ревизии? При создании новых идентификаторов контрольных списков каждый раз, когда редактируется одна из заданий члена, это немного утомительно. – beporter
Нет, вы хотите, чтобы создатель контрольных списков копировал существующий контрольный список (шаблон, как вы сказали), на новый, и позволяет им изменять его и/или задачи перед тем, как перейти к полезному новому идентификатору. – Beth
А это имеет больше смысла. Я не хочу сохранять старые версии по какой-либо причине, кроме * исторических поисков, хотя, чтобы строитель должен был скрыть старую версию после создания новой копии. Неплохой подход. Мне все равно было бы интересно увидеть нереляционный подход к проблеме, хотя бы из любопытства. Это, в конце концов, очень документально-ориентированное и не так много «отношений», которые нужно манипулировать. – beporter