#java #oracle #database-design
Вопрос:
У меня есть сценарий, в котором любое обновление/изменение данных пользователем cms через приложение/CMS требует одобрения администратора/авторизованного пользователя. В одном обновлении в одном документе/записи может быть несколько изменений. Это утверждение не будет выполнено в режиме реального времени и может занять несколько часов или дней. Авторизатор также может отклонить изменение. Итак, в этом случае, каков был бы лучший способ сохранить эти данные живыми, не внося их в базу данных до утверждения или отклонения. Должен ли я создавать временные или дублирующие таблицы, чтобы временно хранить эти данные в базе данных? Но это приведет к большому количеству временных таблиц(по одной для каждой таблицы). Или есть ли какой-либо другой вариант в конце разработчика/приложения/java? Я использую здесь Oracle с Java.
Комментарии:
1. Вам нужно зафиксировать черновую/неутвержденную версии . Существует множество причин, по которым может произойти сбой базы данных или приложения, и вы действительно не хотите, чтобы пользователи потеряли свою работу. Я недостаточно знаю о вашем рабочем процессе, чтобы дать окончательный ответ, но, вероятно, вам нужна структура данных, которая обрабатывает версии документа, отличающиеся статусом утверждения. Это может включать несколько таблиц или нет, это зависит от многих соображений.
2. Вам необходимо различать функциональный поток ( ожидающий утверждения, утвержденный и т.д. ) И целостность базы данных. Вы должны всегда брать на себя обязательства. Существуют различные методы, имеющие разные таблицы для каждой фазы, имеющие флаги в одной таблице для проверки эволюции любой записи. Вы также можете использовать логику SCD.
Ответ №1:
Вам нужно лучше понять проблему. Вам не требуется одно хранилище данных, вам требуется два хранилища данных.
Хранилище данных один (возможно, таблица один) будет содержать неутвержденные изменения. Это и есть «предлагаемое» состояние. Вы запишете и зафиксируете все данные в это хранилище данных, как только пользователь запросит изменение.
Хранилище данных два (возможная таблица два) будет содержать утвержденные изменения; это «реальное» состояние. Как только изменение, содержащееся в хранилище данных one, было рассмотрено и одобрено, вы должны применить это изменение здесь.
Возможным другим решением является использование темы Кафки:
- Используйте раздел Кафки для хранения неутвержденных изменений.
- Передайте тему рецензентам.
- После утверждения отметьте решение (в той же теме) и запишите изменение в базу данных.
Примечание
. хранилище данных 1 и хранилище данных 2 могут быть одной и той же таблицей, просто в столбце должны быть указаны «одобренные изменения», «отклоненные изменения» и «ожидающие изменения».
Комментарии:
1. Наличие отдельных хранилищ данных-это дизайнерское решение, здесь нет «необходимости» . Назначение таблицы только для окончательных версий может дать некоторые преимущества, но это увеличивает сложность приложения и затраты на обслуживание.
2. Я согласен с @APC. Как описано в описании проблемы, «учебное» решение состояло бы в том, чтобы иметь одно хранилище данных и просто иметь столбец для указания статуса записи в рабочем процессе
3. Я согласен как с APC, так и с EdStevens. Кроме того, использование Кафки никогда не было частью операции.
Ответ №2:
Вы всегда можете иметь черновую и окончательную копию данных. Черновая копия сохранит вашу работу в режиме черновика, зафиксирована и операция, такая как сохранение / подтверждение из приложения, может скопировать это в окончательную версию.
Для этого требуется еще одна запись для идентификации черновика / окончательной версии, и вы должны использовать данные черновика для отображения в пользовательском интерфейсе.