Как управлять версией схемы PostgreSQL с комментариями?

Я управляю версией большей части моей работы с Git : код, документация, конфигурация системы. Я могу это сделать, потому что вся моя ценная работа хранится в виде текстовых файлов.

Я также писал и имел дело со многими схемами SQL для нашей базы данных Postgres. Схема включает в себя представления, функции SQL, и мы будем писать функции Postgres на языке программирования R (через PL / R ).

Я пытался скопировать и пропустить схему фрагментов, которую я и мои соавторы пишем, но я забываю это делать. Копия и прошедшее действие повторяются и подвержены ошибкам.

Метод pg_dump / pg_restore не будет работать, потому что он теряет комментарии.

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

Как лучше всего использовать схему контроля версий с комментариями?

Почему бы вам не COMMENT ONразличные SCHEMAкомпоненты, так ваши комментарии в схеме, и будут сброшены.

COMMENT хранит комментарий об объекте базы данных.

Чтобы изменить комментарий, введите новую команду COMMENT для того же объекта. Для каждого объекта хранится только одна строка комментария. Чтобы удалить комментарий, напишите NULL вместо текстовой строки. Комментарии автоматически удаляются при удалении объекта.

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

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

Альтернатива (или вы можете объединить их) моему более раннему предложению состоит в том, чтобы написать свой код SQL в своем редакторе (IDE), сохранить файлы и зафиксировать их в своей VCS, после чего запустите код в базе данных, используя psql -1f. Таким образом, код контролируется версией еще до того, как будет выполнен.

Я работаю в аналогичном проекте. Это мое дизайнерское предложение:

1. Комментируйте объекты БД на регулярной основе, скажем, каждые две недели или два раза в месяц.
2. сделайте все pg_dump (да, получите все, чтобы убедиться, что вы получите все мелкие детали и отношения). Назовите их yyyymmdd-VERSION.dump
3. Если вы используете Git, используйте плагин для больших файлов.

4. Если вы не используете репо, создайте простую таблицу в текстовом формате .CSV, как в таблице ниже:

   version | file name | date | description | 1.0 | yyyymmdd-v10.dump | yyyymmdd | new version of user table | 1.1 | backupDB-v11.dump | yyyymmdd | normalized reports tables |

5. сохраняя связь в CSV-файле сгенерированных дампов по имени файла, вы можете легко их отследить и убедиться, что восстановление будет работать, потому что вы сбросили абсолютно все.

В настоящее время любое облачное хранилище или хранилище на месте не должно быть таким дорогим, даже если речь идет о ТБ данных. Есть некоторые колеблющиеся от 700 до 1000 долларов США до 16 ТБ .

Вы даже можете сэкономить $$$ намного больше, если перейдете в облачное хранилище, подобное наиболее популярному AWS S3.

Если хороший дизайн и стандарты организации определены для отслеживания всей ИТ-инфраструктуры и активов, то после внедрения это не должно быть болезненно, это может быть относительно просто и сэкономит ваши усилия по настройке и, самое главное, время ...