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

Question

У меня есть несколько моделей, записи и связи которых могут иметь два состояния, которые должны сохраняться. Финал и Черновик.

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

Если позднее пользователь захочет изменить эту «форму заявки», ему необходимо отредактировать черновик этой окончательной записи, пока он не представит новую окончательную версию. То есть он не может редактировать предыдущую окончательную форму заявки, пока не установит флажок «окончательный вариант», после чего черновик станет новой окончательной версией.

Уловка в том, что и окончательный, и черновой варианты должны быть связаны с соответствующими записями . То есть связанные с ними записи (например, приложение имеет много контактных лиц) должны храниться таким образом, чтобы их можно было извлечь из окончательной и черновой версий, не смешивая «окончательный» контакт и «черновой» контакт.

В настоящее время я могу придумать два способа решения этой проблемы:

• Используйте ActsAsAudited и проверяйте только окончательные записи. Запрашиваю финалы, когда они мне нужны. (Есть ответвление ActsAsAudited, которое также отслеживает ассоциации). Затем запросите таблицы аудита для получения последних записей.
• Используйте два параллельных набора таблиц данных: один, в котором хранятся черновики, и другой, в котором хранятся только окончательные копии.

Я ДУМАЮ, что хранение финальных и черновых вариантов в одной и той же таблице может дублировать назначение этих таблиц и усложнить соблюдение структуры.

Вам известна какая-либо другая схема или стратегия, которая бы более элегантно справлялась с этой проблемой? Или это уменьшило бы сложность кода?

Вот аналогичный вопрос, который закончился с использованием второй опции выше:

Черновая версия таблицы базы данных

Bernie

Answer 1

Уловка в том, что и у финала, и у черновика есть ассоциации, которые должны быть синхронизированы

Как может окончательно измениться окончательная версия? Окончательные версии должны быть неизменяемыми.

Вы имеете в виду, что кто-то может составить и представить документ, в то время как другие пользователи делают черновики?

Если это так, управление источниками представляется применимым. Был бы полезен вики-подход для слияния документов или простой принцип «блокировки», чтобы два пользователя не могли конфликтовать.

Что касается хранения версионного документа, если вы отказываетесь от использования файловой системы и хотите использовать обычную базу данных, есть два основных подхода:

1. поместите все это в одну таблицу, с флагом для черновика | финала и флагом для «головы» - самой последней окончательной версии каждого документа

2. три таблицы: таблица «голов», отдельная таблица шашек и третья таблица с историческими окончательными версиями

Преимуществом одного подхода перед другим будет производительность и распределение, если система станет действительно большой.

Но если система небольшая, я бы рекомендовал первый подход - одну таблицу - возможно, с тонкостью трех «представлений», чтобы сделать переход на более сложный подход с тремя таблицами менее болезненным в версии 2.0.