База данных, таблица «Статус ожидания»

Question

База данных, таблица «Статус ожидания»

1

У меня уже построенный проект (который использует Spring и JPA). Одна из возможностей позволяет пользователю добавлять место в базу данных (каждое место может быть связано с количеством тегов, их также необходимо одобрить администратором).

Я хотел бы настроить "ожидающую" систему состояний, когда пользователь добавляет новое место, это место добавляется в базу данных (postgreSQL в моем случае), но в "ожидающем состоянии" и на самом деле не рассматривается как последнее место, (тогда администратор должен будет одобрить это место, чтобы сделать его видимым для другого пользователя)

Есть ли какой-либо механизм, который Spring или JPA предлагает для его архивации? Или единственный способ - переделать таблицу и изменить все запросы? (И если да, то какой будет хороший дизайн?, добавив дополнительный столбец (состояние)? Или разделив таблицы и т.д.?

ps: так на данный момент мой дизайн выглядит так:

место таблицы: id_place/name/etc...

table tag: id_tag /name/etc..

table place_tag (который связывает каждый тег с его местом) id/id_place/id_taf Спасибо!

Johny19 27 нояб. 2014, в 02:55

Источник

0

Таким образом, вы хотите добавить строку данных и сделать ее активной только после проверки администратором?
Aeseir 27 нояб. 2014, в 02:18
0

точно, учитывая, что мой проект довольно большой. Каков наилучший способ архивировать это? Имея новый дизайн базы данных (это будет означать большой рефакторинг, так как все существующие запросы будут разбиты) Или иметь дублирующуюся таблицу "pending_place, pending_tag и pending_place_tag)?
Johny19 27 нояб. 2014, в 02:21
0

Кроме того, у нас есть дополнительный столбец «validated», который представляет собой tinyint. Когда пользователь отправляет информацию, она остается ложной, поэтому они могут просматривать, но она не активна, когда администратор подтверждает, что она становится истинной, а затем данные становятся активными в приложении. Это самый простой способ сделать это. Рад сделать это официальным ответом, если хотите
Aeseir 27 нояб. 2014, в 02:23
0

Да, это был также один из моих подходов, но это лучший подход (это, конечно, легко, но я ищу здесь лучший дизайн). Также я завершил свой оригинальный вопрос. Означает ли это, что мне также придется добавить дополнительный столбец в мою 2 другую таблицу?
Johny19 27 нояб. 2014, в 02:25
0

Лучше всего иметь минимальные изменения и максимально нормализовать их (дизайн базы данных). Это зависит от того, насколько велика база данных, как она управляет всеми этими факторами. Из того, что я видел, лучше всего добавить один столбец в существующую таблицу с крошечным набором данных, так как бизнес-логика кода и функционального кода также не нуждаются в серьезных изменениях (так что меньше шансов запутаться в долгосрочной перспективе)
Aeseir 27 нояб. 2014, в 02:28
0

Если вы работали непосредственно с БД, а не через JPA, вы могли бы использовать для этого обновляемое представление.
Craig Ringer 27 нояб. 2014, в 05:23
0

@CraigRinger, как предположил Эсейр, добавление нового столбца кажется хорошей идеей. Если я правильно понял, вид будет выглядеть примерно так: CREATE VIEW place_view AS SELECT * из места, где проверено = 'Y'. Затем я пройду по всем моим запросам и поменяю "from", чтобы он использовал мой place_view. Не поддерживается ли использование представления с сущностями JPA?
Johny19 27 нояб. 2014, в 10:37
0

@Johny19 Johny19 Конечно, вы можете использовать представление с JPA, проблема в том, что JPA не позволяет легко переключаться между представлением и базовой таблицей. Вы можете справиться с этим, используя поддельные отношения наследования, несколько сущностей для сопоставления одних и тех же таблиц или несколько других приемов, но может быть проще просто использовать собственные запросы, когда вы хотите манипулировать базовой таблицей.
Craig Ringer 29 нояб. 2014, в 06:08

Показать ещё 6 комментариев

Теги:

java

postgresql

spring

jpa

1 ответ

Ещё вопросы

Таким образом, вы хотите добавить строку данных и сделать ее активной только после проверки администратором?
точно, учитывая, что мой проект довольно большой. Каков наилучший способ архивировать это? Имея новый дизайн базы данных (это будет означать большой рефакторинг, так как все существующие запросы будут разбиты) Или иметь дублирующуюся таблицу "pending_place, pending_tag и pending_place_tag)?
Кроме того, у нас есть дополнительный столбец «validated», который представляет собой tinyint. Когда пользователь отправляет информацию, она остается ложной, поэтому они могут просматривать, но она не активна, когда администратор подтверждает, что она становится истинной, а затем данные становятся активными в приложении. Это самый простой способ сделать это. Рад сделать это официальным ответом, если хотите
Да, это был также один из моих подходов, но это лучший подход (это, конечно, легко, но я ищу здесь лучший дизайн). Также я завершил свой оригинальный вопрос. Означает ли это, что мне также придется добавить дополнительный столбец в мою 2 другую таблицу?
Лучше всего иметь минимальные изменения и максимально нормализовать их (дизайн базы данных). Это зависит от того, насколько велика база данных, как она управляет всеми этими факторами. Из того, что я видел, лучше всего добавить один столбец в существующую таблицу с крошечным набором данных, так как бизнес-логика кода и функционального кода также не нуждаются в серьезных изменениях (так что меньше шансов запутаться в долгосрочной перспективе)
Если вы работали непосредственно с БД, а не через JPA, вы могли бы использовать для этого обновляемое представление.
@CraigRinger, как предположил Эсейр, добавление нового столбца кажется хорошей идеей. Если я правильно понял, вид будет выглядеть примерно так: CREATE VIEW place_view AS SELECT * из места, где проверено = 'Y'. Затем я пройду по всем моим запросам и поменяю "from", чтобы он использовал мой place_view. Не поддерживается ли использование представления с сущностями JPA?
@Johny19 Johny19 Конечно, вы можете использовать представление с JPA, проблема в том, что JPA не позволяет легко переключаться между представлением и базовой таблицей. Вы можете справиться с этим, используя поддельные отношения наследования, несколько сущностей для сопоставления одних и тех же таблиц или несколько других приемов, но может быть проще просто использовать собственные запросы, когда вы хотите манипулировать базовой таблицей.

Aeseir · Answer 1 · 2014-11-27T00-58-00.000Z

В соответствии с комментариями и обсуждением наиболее распространенным и эффективным способом я увидел, что это реализовано и сделано, включив дополнительный столбец в существующие таблицы, например, "проверенный".

Некоторые преимущества включают:

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

И снова это изменится на основе мнения, опыта, сложности системы и т.д.

Надеюсь, поможет.