Я тоже делаю то же самое. Я делаю базу данных для планов уроков. Эти планы нуждаются в гибкой версионности атомных изменений. Другими словами, каждое изменение, независимо от того, насколько оно мало, в планах урока, должно быть разрешено, но старая версия также должна быть сохранена. Таким образом, создатели уроков могут редактировать планы уроков, пока ученики их используют.
То, как он будет работать, состоит в том, что, как только ученик сделает урок, его результаты будут приложены к версии, которую он закончил. В случае внесения изменений их результаты всегда будут указывать на их версию.
Таким образом, если критерии урока удалены или перемещены, их результаты не изменятся.
В настоящее время я делаю это, обрабатывая все данные в одной таблице. Обычно у меня было бы только одно поле id, но в этой системе я использую id и sub_id. Sub_id всегда остается со строкой, через обновления и удаления. Идентификатор автоматически увеличивается. Программное обеспечение плана урока свяжется с самым новым sub_id. Результаты студента будут ссылаться на идентификатор. Я также включил временную метку для отслеживания, когда произошли изменения, но нет необходимости обрабатывать версии.
Одна вещь, которую я мог бы изменить, после того как я проверил это, я мог бы использовать ранее упомянутую идею нулевого конца endDate. В моей системе, чтобы найти самую новую версию, мне нужно найти max (id). Другая система просто ищет endDate = null. Не уверен, что у льгот нет другого поля даты.
Мои два цента.