Обычно наоборот, добавляешь в коде, генерируешь скрипт миграции
Так или иначе, это не спасёт от необходимости внести упомянутые 30–40 обновлений.
--
Помимо структуры, которая будет нужна приложению, будут и вещи, о которых оно вряд ли должно знать — условные пользователи, роли, файловые группы и т.д. Т.е БД управляют не как целостной сущностью, а размазывают ее по разным местам. Какой вариант централизации предполагается?
Даже если откинуть вопрос структуры, получается, что всё описание переносится из SQL-проекта (будь то SSDT или что-то другое) в проект с приложением/контекстом на C#. То есть вместо прямого DDL пишется C# со всеми вытекающими, что вряд ли будет короче.
Не говоря уже о том, что помимо непосредственной зависимости появляется еще и зависимость от пакетов: расхождения в версиях фреймворка между проектами, фиксах, которые нужно обновлять во всех проектах. То есть, к управлению добавляется еще и языковая инфраструктура.
Для маленьких систем ещё понимаю, но когда тебе нужно при добавлении колонки в таблицу, обновить 30-40 запросов вручную...
Для чего? Если они не используются, то их и не надо обновлять, в противном случае запросы в приложениях тоже придется обновлять.
А вот без ORM нужно следить за актуальностью запрашиваемых полей
При использовании ORM не нужно обновлять контекст с описанием используемых таблиц? Все подхватится и добавится автоматически?
Фактически структура БД будет дублироваться: сначала условный DDL, а затем обновить контекст, аннотации и т.п.
А если контекст находится в отдельном репозитории или поставляется в виде отдельного пакета..
--
Кроме того, все запросы проходят мимо DBA, что в случае их неоптимальных затрудняет исправление возникших из-за них проблем.
Для маленьких систем ещё понимаю
Что такое маленькая система?
--
Не знаю, какой инструмент считается наиболее популярным и гибким для работы с БД проектами под PostgreSQL, но под SQL Server есть SSDT, который позволяет работать в привычной для разработчиков манере (как с точки зрения разработки, так и с точки зрения CI/CD). В сочетании с хранимыми процедурами это просто сказка.
Решение должно быть универсальным и легко адаптируемым к разным средам
В данном случае оно не является универсальным, т.к предполагает наличие K8S.
Почему бы не запускать создание резервной копии через CI систему? Она не зависит от системы оркестрации и удовлетворяет остальным требованиям (изоляция, журналирование, мониторинг).
---
Не описан обратный процесс, т.е импорт резервная копии в RabbitMQ.
Если в кластере был потерян кворум, то это приведет к перманентной недоступности очередей типа Quorum, их потребуется пересоздать. Импорт не приводит к пересозданию объектов.
---
Если исходить исходить из того, что объекты в рамках RabbitMQ (exchange, queue, vhost, policy) статичные, то их создание через Terrafrom (состояние автоматически выгружается в бакет) + CI (журналирование, мониторинг) будет неплохим решением. За сохранность временных объектов (полагаю к таким можно отнести только очереди) отвечало бы приложение (по сути их потеря не должна быть критичной).
Где-то я такое уже видел
Хотя эти вопросы больше о сне, чем о QPS. С другой стороны, одно может привести к другому.
Так или иначе, это не спасёт от необходимости внести упомянутые 30–40 обновлений.
--
Помимо структуры, которая будет нужна приложению, будут и вещи, о которых оно вряд ли должно знать — условные пользователи, роли, файловые группы и т.д. Т.е БД управляют не как целостной сущностью, а размазывают ее по разным местам. Какой вариант централизации предполагается?
Даже если откинуть вопрос структуры, получается, что всё описание переносится из SQL-проекта (будь то SSDT или что-то другое) в проект с приложением/контекстом на C#. То есть вместо прямого DDL пишется C# со всеми вытекающими, что вряд ли будет короче.
Не говоря уже о том, что помимо непосредственной зависимости появляется еще и зависимость от пакетов: расхождения в версиях фреймворка между проектами, фиксах, которые нужно обновлять во всех проектах. То есть, к управлению добавляется еще и языковая инфраструктура.
Для чего? Если они не используются, то их и не надо обновлять, в противном случае запросы в приложениях тоже придется обновлять.
При использовании ORM не нужно обновлять контекст с описанием используемых таблиц? Все подхватится и добавится автоматически?
Фактически структура БД будет дублироваться: сначала условный DDL, а затем обновить контекст, аннотации и т.п.
А если контекст находится в отдельном репозитории или поставляется в виде отдельного пакета..
--
Кроме того, все запросы проходят мимо DBA, что в случае их неоптимальных затрудняет исправление возникших из-за них проблем.
Что такое маленькая система?
--
Не знаю, какой инструмент считается наиболее популярным и гибким для работы с БД проектами под PostgreSQL, но под SQL Server есть SSDT, который позволяет работать в привычной для разработчиков манере (как с точки зрения разработки, так и с точки зрения CI/CD). В сочетании с хранимыми процедурами это просто сказка.
Добавить бы возможность видеть наличие (кол-во) комментариев в списке вакансий. Иначе сложно оценить охват
Решение должно быть универсальным и легко адаптируемым к разным средам
В данном случае оно не является универсальным, т.к предполагает наличие K8S.
Почему бы не запускать создание резервной копии через CI систему? Она не зависит от системы оркестрации и удовлетворяет остальным требованиям (изоляция, журналирование, мониторинг).
---
Не описан обратный процесс, т.е импорт резервная копии в RabbitMQ.
Если в кластере был потерян кворум, то это приведет к перманентной недоступности очередей типа Quorum, их потребуется пересоздать. Импорт не приводит к пересозданию объектов.
---
Если исходить исходить из того, что объекты в рамках RabbitMQ (exchange, queue, vhost, policy) статичные, то их создание через Terrafrom (состояние автоматически выгружается в бакет) + CI (журналирование, мониторинг) будет неплохим решением. За сохранность временных объектов (полагаю к таким можно отнести только очереди) отвечало бы приложение (по сути их потеря не должна быть критичной).