Як керувати версіями 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 all (так, отримайте все, щоб переконатися, що ви отримаєте всі дрібні деталі та стосунки). Назвіть їх по 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

Якщо гарний дизайн та стандарти організації визначені для того, щоб відслідковувати всю ІТ-інфраструктуру та активи, це не повинно бути болісним після їх впровадження, це може бути відносно простим та заощадить ваші болі в конфігурації, а головне - час ...