Как синхронизировать таблицу и представление в PostgreSQL?

Question

[nurzhannogerbek]

Здравствуйте, коллеги! Помогите пожалуйста разобраться.

Есть простая таблица в базе данных PosgreSQL. Структура этой таблицы выглядит следующим образом.

| ID | REPORT_TYPE | STATUS | USER_EMAIL     |
|--------------------------------------------|
| 1  | sms         | 0      | [e-mail]  |
| 2  | call        | 1      | [e-mail] |
| 3  | internet    | 2      | [e-mail] |

Пытаюсь создать идентичное по структуре представление (view) на основе этой таблицы. То есть если в таблице появляется новая запись со статусом 0, ее нужно занести в представление. Если в таблице у какой либо записи меняется значение статуса на 0, она появляется в представлении. Одним словам пытаюсь синхронизировать таблицу и представление в PostgreSQL. Подскажите, как это реализовывается?

Answer 1

[Melkij]

Если вы говорите именно о view - то я вас вовсе не понимаю.
В view в принципе нет и не может быть ни одной строки, в сам view невозможно ничего записать (writable view - это переписывание запроса). Когда вы обращаетесь к view - в запрос идёт запрос из объявления этого view и весело анализируется/переписывается как любой другой запрос.

То есть что с чем вы пытаетесь синхронизировать? Запрос с другим запросом? У вас данные всего в одном месте, нечего синхронизировать здесь.

Если вы говорите всё-таки о материализованном представлении - то вам нужен отдельный запрос refresh materialized view. Вообще matview by design для неактуальных данных и задаче периодической актуализации через refresh.

Comments

[nurzhannogerbek]

Здравствуйте! Я вот не знаю, что лучше всего использовать в моей ситуации. View или Materialized View? К примеру в таблице "REPORT" есть столбец "STATUS". Он показывает статус отчета. Мне нужно отдельно хранить где-то все записи (отчеты) из таблицы "REPORT" в которых значение столбца STATUS равен нулю. К примеру если создается новая запись у которой статус ноль, она должно попасть в представление. Если у какой-то уже существующей записи, поменяли статус на ноль, то она должно попасть в то представление. Если в записи со статусом ноль поменяли значение других столбцов, то эти изменения должны быть и у записи в представлении. Если у записи со статусом ноль поменяли значение на 1 или 2, то запись из представления должна исчезнуть. Под синхронизацией я имел введу это. Что можете сказать по этому поводу.

[Melkij]

Мне нужно отдельно хранить где-то все записи (отчеты) из таблицы "REPORT" в которых значение столбца STATUS равен нулю.

Начните отсюда: зачем хранить отдельно?
Может быть, вам не хранить их отдельно надо, а получать приложению? Обычный where в запросе.

[nurzhannogerbek]

Melkij, Здравствуйте! Знаю, что можно условием WHERE STATUS=0 вытащить, но здесь вопрос в другом был.

[Melkij]

NogerbekNurzhan, и в чём же вопрос? Ответьте зачем вам хранить отдельно.

- глупое приложение не умеет писать where? Ок, сгодится. Вам нужен view. View в принципе не может быть не синхронизирован с таблицей. Потому что это view.
- если у вас хотя бы пара сотен гигабайт данных в табличке - тогда я могу понять, зачем гипотетически может быть нужно именно хранить отдельно. Но сомневаюсь, что партицирование по статусу при этом осмысленно. При том само поле статуса в таблице отчётов с ощутимой вероятностью свидетельствует о том, что это какая-то очередная самописная очередь в базе непригодная к работе под нагрузкой и развалится на смешных сотнях rps.
- тараканы насоветовали? А чем аргументировали эту странную необходимость?