AD
У вас же база изменяется через миграции? Вот добавьте туда какой-нибудь хук, который будет уведомлять тогда, когда новая миграция заезжает
Да не надо так делать)) Кучу проблем породит
Size: a a a
2021 March 12
D
Да не надо так делать)) Кучу проблем породит
А чем это хуже, чем "Можно написать рутину, которая будет ходить в источник, забирать инфу об объектах, сверять с той, что нужна, затем в зависимости от критичности слать алерты ответственным лицам"?
AD
Тем, что будет происходить какая-то неконртролируемая вещь со скриптами. Как минимум про ambiguity человек выше написал, но проблем может вылезти и больше
D
Тем, что будет происходить какая-то неконртролируемая вещь со скриптами. Как минимум про ambiguity человек выше написал, но проблем может вылезти и больше
В смысле? Кроном раз в час проверяете таблицу миграций и смотрите последнюю запись там)
ac
Ещё предложу вариант работать через ORM, и "схема базы — это данные".
D
Ещё предложу вариант работать через ORM, и "схема базы — это данные".
Аналитики свои запросы через ORM едва ли смогут сделать
AD
Смотрите
была табла
order_id
datetime
amount
Поверх написан скрипт, который считает средний amount за период (это пример)
Стало
order_id
datetime
amount_per_good
goods_cnt
Что делать скрипту?
была табла
order_id
datetime
amount
Поверх написан скрипт, который считает средний amount за период (это пример)
Стало
order_id
datetime
amount_per_good
goods_cnt
Что делать скрипту?
AD
Это тупой кейс для примера, но он иллюстрирует проблему
AD
Скрипт ничего не знает про логику
AD
Правильно в такой ситуации алертить тем, кто эти скрипты писал, чтобы они пришли и починили свои запросы
D
Смотрите
была табла
order_id
datetime
amount
Поверх написан скрипт, который считает средний amount за период (это пример)
Стало
order_id
datetime
amount_per_good
goods_cnt
Что делать скрипту?
была табла
order_id
datetime
amount
Поверх написан скрипт, который считает средний amount за период (это пример)
Стало
order_id
datetime
amount_per_good
goods_cnt
Что делать скрипту?
Взять список миграций из таблицы migrations, которые появились позже, чем та, которую он "помнил" (в Redis держал, например). Для этих миграций вытащить запросы из системы контроля версий (где сами миграции лежат) и закинуть их в чат к аналитикам, чтобы они починили свои запросы в соответствии с изменениями.
AD
А, то есть вы предлагаете алертить при любых изменениях в объектах. Ну тоже вариант
D
А, то есть вы предлагаете алертить при любых изменениях в объектах. Ну тоже вариант
Ну да, поэтому и предложил миграции смотреть
AD
Если взять частный кейс с пользователями-аналитиками, правильнее будет написать что-то своё, чему всё равно, какой там источник — база, csv, гуглодок, etc
AD
Но в вопросе этого не было, поэтому не факт, что так лучше для всех)
ac
Yaroslav Schekin
Потому что CREATE не параметризуются в принципе (а вообще функция выглядит как-то очень странно — зачем view пересоздавать при каждом вызове, что это вообще за подход?!).
Я даже не хочу подсказывать, как тут дальше выстрелить себе в ногу, если честно. ;(
Я даже не хочу подсказывать, как тут дальше выстрелить себе в ногу, если честно. ;(
Я подскажу :)
Создайте отдельную таблицу с ids, процедура будет обновлять её содержимое, а VIEW объявите раз и навсегда через JOIN этой таблицы
Создайте отдельную таблицу с ids, процедура будет обновлять её содержимое, а VIEW объявите раз и навсегда через JOIN этой таблицы
ГР
как вывести комментарии с названиями полей? \d+ table_name выводит несколько ненужных колонок
YS
Геннадий Романов
как вывести комментарии с названиями полей? \d+ table_name выводит несколько ненужных колонок
"Содрать" из него запрос (с помощью "\set ECHO_HIDDEN yes"), модифицировать "под себя".
МШ
Ребят, заморочился со следующим вопросом. Я строю базу, периодически меняю названия столбцов. К этой базе другие пользователи делают запросы. Соответственно, если я поменяю названия столбца, то у них перестанут работать запросы. Хотелось бы, чтобы при переименовании столбца, переименовывались названия столбца в запросах пользователей. Какие то готовые решения есть для этого?
Универсальное решение, которое приходит в голову - веб-морда с генератором отчётов, код которой будет меняться в соответствии с манипуляциями с объектами БД.
ДМ
Я подскажу :)
Создайте отдельную таблицу с ids, процедура будет обновлять её содержимое, а VIEW объявите раз и навсегда через JOIN этой таблицы
Создайте отдельную таблицу с ids, процедура будет обновлять её содержимое, а VIEW объявите раз и навсегда через JOIN этой таблицы
Ids каждый раз новые.