Добрый день! Начинаю осваивать по-тихоньку Postgres в рамках импортозамещения в

компании) )) Сам SAPом занимаюсь, пока что, по инерции так сказать) Установил я posgresql себе на компьютер, попробовал селекты через их тестовую БД demo,потыкал в PGAdmin. Есть два вопроса:
1) Где лучше всего найти материал по работе с PGAdmin?
2) Где можно посмотреть, как настроить ландшафты разработка-> тест -> продуктив?

1) psql вам в помощь. Лучше сразу учиться работать в ней. Это единственный "родной" клиент. Хотя PgAdmin и является стандартом ГУЙни де факто. 2) Понятие ландшафты - это ваша заморочка. Расшифровывайте.

"Хотя PgAdmin и является стандартом" - это откуда инфа? Все знакомые Dbeaver юзают

Ну а по факту для Пг стандартом дефакто является PgAdmin. Но вы вольны использовать что угодно, конечно.

Я имею в виду, где это указано? В документации?

У вас проблемы со словом "де факто"?

Понял, спасибо. А у Postgres есть понятие впринципе, система разработки, система теста и т.д.? Допустим внесли какие то изменения в таблицу, добавили новую колонку в таблицу например. Дальше эти изменение переехали из разработки в тест, где в этой таблице хранится больше данных, которые относятся к этой таблице

Если я правильно понимаю нет. Есть просто несколько баз данных.

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

А изменения между одной Базы Данных и другой можно переносить? Допустим, вот изменения структуры данных в одной таблице мы переносим, а другие изменения( в другой таблице) пока что в разработке и мы их никуда не переносим

вот я пытаюсь разобраться, что и как с этим едят так сказать)

Миграции ))

у вас тут свой мир, понимаю, не бейте больно😂 Могу глупости говорить, в вашем понимании

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

У нас БД - это просто БД, сервис хранения данных. Это не как "конфигурация" в 1С или что-то аналогичное в SAP. Отсюда и подходы.

Посмотрите такие библиотеки как Liquibase и Flyway.

угу, понял, спасибо!

Понял, хорошо, спасибо. А updates.sql это что? а то я гуглю, какой то шлак на выходе получаю

Фаил с SQL командами, которые надо выполнять при обновлении )))

ааа ахахах)) понял

Сергей, добрый день! Посдкажите пожалуйста, я правильно понимаю, что помимо Liquibase нужно сверху ещё иметь Spring boot?

Нет, его можно использовать отдельно.

его можно использовать даже без джава приложения

Вот тут посмотрите: https://docs.liquibase.com/install/home.html https://docs.liquibase.com/parameters/working-with-command-parameters.html

Да, я вот начал смотреть, но если много разрабов, это ведь не жизнеспособно( я могу ошибаться), чтобы каждый в командную строку, что то вводил.

разраб пишет только файл с миграцией который кладет в гит, дальше CI/CD раскатывает на прод

файлы ченджлогов хранятся в гите а дальше вводить надо только что-то вроде liquibase --change-log-file=dbchangelog.xml update

А разраб имеет доступ к PGAdmin, это вообще нормальная практика там вести разработку? А change-log будет фиксировать сделанные там изменения?

WTF??? для того чтобы залезть в базу не нужен графический интерфейс, хватит psql или чего угодно что умеет в протокол pg, что вы понимаете под разработкой в pg_admin мне страшно представить даже А change-log будет фиксировать сделанные там изменения? да да и еще раз да, и никак иначе

Как это я такой жЫр пропустил?! Стандартом де-факто является консоль psql.

А такжэ и дэ-юрэ.

Ну вы еще отматайте назад

логично с учетом того что она входит в состав утилит поставляемых с pg

Только виндового комплекта от edb.

Справедливости ради, если планируется использование pgagent'а, то pgadmin - единственный клиент с интерфейсом настройки job'ов (правда, мы их у себя деплоим с помощью скриптов, заполняющих соответствующие таблички, так что можно и без этого интерфейса жить, хотя с ним удобнее). Плюс, именно в pgadmin'е впервые появилась поддержка pldebugger'а, хотя назвать pgadmin ideшкой язык не поворачивается. Сейчас поддержка отладки есть в ems SQL manager-е и datagrip (оба платные).

появилась поддержка pldebugge ну хз, если по честному называть это поддеркжкой язык не поворачивается, технически работает, но сделано на от*****

А если ещё и планируется использование pgadminа - то pgadmin оказывается абсолютно незаменимым!

А где сделано нормально? После у тех, кто разрабатывал под oracle в pl/sql developer-е, любая ide для postgresql (даже datagrip) вызывает тоску.

Я лет 7 мучался с дебаггерами разными -- пока не понял, что это абсолютно вредная хрень при разработке. (Притом понял это примерно в районе писание web-скриптов на perl, ни одного postgresа при этом не было).

это вы в контексте баз данных или вообще про ЯП?

Вообще. Основной БД у меня тогда были mysql/msql, второй -- gdbm/berkley db. Дебаггеров там не то что не было -- дажэ мысли, что к этому можно подойти с дебаггером не возникало.

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

В нормальной среде (разработка веб-скриптов, зачастую, к таким не относится) отладчик - самый быстрый способ разобраться в том, что происходит и найти ошибку. В языках с наиболее празвитой поддержкой отладки это также возможность исправить проблему на месте, не прерывая отладочную сессию. Да, можно часть этих задач выполнить добавлением логирования, но это занятие весьма непродуктивно и требует кучи запусков кода до того, как выяснится, что не так. Если вы умеете исполнять код в голове, можно обойтись без отладки, но рано или поздно сложность кода может превысить ваши возможности, либо вы что-то упустите по невнимательности. Отладка же позволяет избежать этих проблем (исключая некоторые плохие примеры, когда отладка эмулируется отдельным интерпретатором, который может работать не так, как работает реальный код).

>отладчик - самый быстрый способ разобраться в том, что происходит и найти ошибку. Нет. Ужэ отладочная печать -- куда быстрее тупой дрочильни отладчика. Более правильное -- конечно -- unit тэсты с настраиваемыми журналами. >Да, можно часть этих задач выполнить Все. Все эти задачи (если у тебя есть исходники) можно выполнить отладочной печатью. >о и требует кучи запусков кода до того, как выяснится Это отладка дебаггером требует кучи запусков как раз. Журнал ты один раз добавил в несколько правильных мест, включил -- получил лог, из которого всё понятно. И не только сейчас, и не только тебе. Отладку надо перезапускать много раз, поскольку когда ты первый раз видишь проблему -- обычно всё ужэ сломано где-то на предыдущем этапе.

Отладку надо перезапускать много раз, поскольку когда ты первый раз видишь проблему -- обычно всё ужэ сломано где-то на предыдущем этапе. если все упало то это значит у вас самый легкий тип багов, а ведь есть и куда более сложные, которые вам ничего и никогда не положат

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

Отладочная печать не позволит приостановить выполнение кода, подумать и быстро модифицировать какие-то локальные переменные так, чтобы исполнение пошло в ту ветку, которая вам нужна. Придётся останавливать выполнение(, компилировать) и запускать заново. Также, отладочная печать достаточно осложняет изучение состояния стека.

>Также, отладочная печать достаточно осложняет изучение состояния стека. Скорее упрощает.

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

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

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