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

Question

У меня есть база данных с таблицей отчетов. Эта таблица представляет данные отчета и имеет ограничения. Теперь приложение используется пожарными, и им, возможно, придется убежать и потушить несколько пожаров. Так что в середине заполнения данных для этой таблицы, возможно, им придется убежать. Что мы делаем, когда сеанс заканчивается, мы сохраняем данные в черновой таблице, где мы просто сериализуем граф объекта, без ограничений (так как мы не можем знать, находится ли все в действительном состоянии). И когда пожарный позже хочет извлечь данные, мы просто снова вытягиваем черновик.

Это отлично работает! Однако теперь пожарные хотят иметь возможность обыскивать стол и черновой стол. Поэтому здесь я хотел бы, возможно, сохранить все данные (включая черновик) в одну таблицу, в которой я веду поиск, поэтому мне не нужно объединять результаты поиска по двум таблицам.

Есть ли какой-то шаблон базы данных для черновиков? Мне нужен шаблон для хранения данных без ограничений (в черновом режиме) и с ограничениями (в конечном режиме).

Answer 1

Я не знаю, будет ли это квалифицироваться как шаблон, но я думаю, что самым чистым способом для этого было бы создание представления, объединяющего две таблицы и осуществляющего поиск по нему.

Answer 2

Я думал довольно долго и трудно об этой проблеме, и вот мой ответ:

1. хранить черновики и соответствующие им проверенные объекты в одной таблице. есть столбец is_draft

2. используйте is_draft = 1, чтобы отключить проверку в триггерах и проверить ограничения или ваши правила проверки ORM

3. многие из ваших полей должны быть обнуляемыми или иметь значения по умолчанию

это имеет несколько преимуществ:

1. черновики и соответствующие им утвержденные объекты хранятся в одной таблице

2. черновики и соответствующие им утвержденные сущности имеют одинаковые идентификаторы . почему это важно?

представьте, что вы начинаете цитату для клиента. сохрани это. он получает идентификатор. вы смотрите на это в веб-браузере / quotes / id / 55. вы начинаете редактировать эту цитату, удаляя обязательное значение, потому что оно было неверным. Вы должны пойти по соседству, чтобы найти его, но вы хотите сохранить его. Идентификационный номер не должен меняться.

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

Answer 3

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

На самом деле я бы не стал объединять полные и черновые данные в любой момент: вероятность ошибки и случайного использования непроверенных данных кажется огромной.

Вы бы сейчас не работали над интерфейсом для IRS в Великобритании, не так ли? Если нет, звучит так, будто DK пошли на подобное (в принципе) решение этой проблемы (я работал в пожарной и спасательной службе Великобритании).

Answer 4

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