Комментарии 35
НЛО прилетело и опубликовало эту надпись здесь
Для нас хранимые процедуры удобны, в первую очередь тем, что это безопасно, плюс не надо передавать гигабайты данных между базой и приложением. Удобно сделать несколько действий с разными таблицами в базе, а в приложение только отчитаться о том, что всё было выполнено успешно. Это действительно удобно.
НЛО прилетело и опубликовало эту надпись здесь
Здравствуйте!
Насколько я понял, именно выделение бизнес-логики в хранимые процедуры позволяет упростить разработку и поддержку приложения.
При использовании соотвутствующих инструментов появляется возможность проводить тестирование этой самой бизнес-логики на стороне БД. Может быть это излишне или даже не нужно (я не специалист но разработке БД), но, как показывает мой не слишком богатый опыт, позволяет меньше усилий тратить при разработке и тестировании кода приложения, использующего БД.
Насколько я понял, именно выделение бизнес-логики в хранимые процедуры позволяет упростить разработку и поддержку приложения.
При использовании соотвутствующих инструментов появляется возможность проводить тестирование этой самой бизнес-логики на стороне БД. Может быть это излишне или даже не нужно (я не специалист но разработке БД), но, как показывает мой не слишком богатый опыт, позволяет меньше усилий тратить при разработке и тестировании кода приложения, использующего БД.
А зачем с одной БД вообще работать из разных версий кода? Можно же сделать легковесный бекап для разработчиков и тестовых серверов, и разворачивать по схеме «каждому инстансу — своя БД». Ну и выкатывать все тоже вместе — и миграции БД, и хранимки, и код, который это все использует.
На сколько я понял, второй метод чем-то похож, только решение через схемы, а не БД. Но все равно попахивает одним большим костылем…
1. Атомарно нельзя выкатить несколько серверов с кодом приложения. Таким образом одновременно может вызываться старый и новый код на базе.
2. Быстрый деплой и особенно откат.
3. Проведение нагрузочного тестирования на staging (для сотен разработчиков * n веток потребуется очень много ресурсов для создания индивидуального staging окружения)
2. Быстрый деплой и особенно откат.
3. Проведение нагрузочного тестирования на staging (для сотен разработчиков * n веток потребуется очень много ресурсов для создания индивидуального staging окружения)
и как это все увязывается с DDL?
Мы используем мигратор и обратно совместимые миграции.
А как вы работаете с миграциями? Свой инструмент или сторонний? Просто на моей прошлой работе миграции складировались по папкам(именовали папки датами и вели учет в версионность вели в табличке Excel) и вручную заливались на каждый сервер БД(а их было где-то 15 штук). Как вспомню, так вздрогну.
Добрый вечер!
Мы создали свой инструмент, который очень похож на продукты с открытым исходным кодом.
Информация о примененных миграциях хранится в той же базе, на которую они накатываются.
Мы создали свой инструмент, который очень похож на продукты с открытым исходным кодом.
Информация о примененных миграциях хранится в той же базе, на которую они накатываются.
Расскажите, как в вашем случае с вашим инструментом реализуется возможность посмотреть структуру базы данных на определенном коммите в SCM?
Часть существующих решений предлагает хранить только миграции и нулевую версию схемы, часть предлагает свой вариант DDL и генерацию миграций из его диффа.
Добрый день!
Мы тоже храним файлы с миграциями в sql-формате.
Поэтому на определённом коммите можем посмотреть только сами миграции.
Свои варианты DDL (отличные от sql) не рассматривались в принципе, так как требуют разработки (что очень непросто) и изучения теми, кто будет их использовать.
Если говорить простым языком, то:
Понимаете, всё предельно просто и не требует никаких специальных знаний.
Мы тоже храним файлы с миграциями в sql-формате.
Поэтому на определённом коммите можем посмотреть только сами миграции.
Свои варианты DDL (отличные от sql) не рассматривались в принципе, так как требуют разработки (что очень непросто) и изучения теми, кто будет их использовать.
Если говорить простым языком, то:
- Миграции в sql-формате разложены по подпапкам с именами баз данных (их много) в репозитории с проектом;
- Мигратор накатывает неприменённые миграции последовательно на каждую базу данных и заносит информацию о применении миграции в служебную таблицу в той же базе;
- Миграции делятся на два вида: линейные (простые) и повторяемые. Линейные выполняются один раз. Повторяемые выполняются каждый раз, как только меняется контрольная сумма sql-файла.
Понимаете, всё предельно просто и не требует никаких специальных знаний.
А в случае изменения структуры таблиц?
Проходится всегда делать обратно совместимые изменения и чистить устаревшее?
Проходится всегда делать обратно совместимые изменения и чистить устаревшее?
dbprojector.net — Позволяет делать сравнение декларативной схемы в проекте и реальной схемы на существующей произвольной БД и автоматически генерирует DDL для апдейта к новой версии схемы БД.
Заморочился в свое время, только сейчас пиарить времени нет. Умеет в том числе и генерить DDL для альтера таблиц. Хоть PG и кривой в этом плане. Только это не сильно кому нужно т.к. действительно логика в БД — зло.
Заморочился в свое время, только сейчас пиарить времени нет. Умеет в том числе и генерить DDL для альтера таблиц. Хоть PG и кривой в этом плане. Только это не сильно кому нужно т.к. действительно логика в БД — зло.
Продолжая вашу категоричную мысль:… а писать одинаковую логику на нескольких языках – добро.
Положим n – количество портов вашего приложения. Тогда в случае изменения логики, менять придётся не одну хранимую процедуру/триггер/constraint, а n исходных текстов. Имея процент ошибок, при написании текста программ, например, 0.5% от написанного, вы этот процент, опять же, увеличиваете в n раз.
Положим n – количество портов вашего приложения. Тогда в случае изменения логики, менять придётся не одну хранимую процедуру/триггер/constraint, а n исходных текстов. Имея процент ошибок, при написании текста программ, например, 0.5% от написанного, вы этот процент, опять же, увеличиваете в n раз.
НЛО прилетело и опубликовало эту надпись здесь
Для этого давно изобретена сервисная архитектура, где мы закрываем прямой доступ к БД и где у нас намного больше свободы и возможностей для формирования нормального, явно выраженого слоя API. Для доступа от разных платформ можно например сделать HTTP REST сервис. Нет наверно таких платформ которые не могут использовать такие сервисы. Заодно и возможностей для маневра в случае чего остается намного больше.
И я ни в коем случае не пытаюсь утверждать, что делать так всегда плохо, а вот так всегда хорошо. Все зависит от задачи, исходных условий и т.д. Я только говорю что формировать слой API в БД на хранимках обычно не самая лучшая идея.
И я ни в коем случае не пытаюсь утверждать, что делать так всегда плохо, а вот так всегда хорошо. Все зависит от задачи, исходных условий и т.д. Я только говорю что формировать слой API в БД на хранимках обычно не самая лучшая идея.
Спасибо за статью, Николай, я правильно понимаю, что для каждой тестовой сборки тоже потребуется создать свой search_path.
И у вас есть пул из N доступных search_path.
Не получается ли такое, что при N+1 тестовых сборок, старые слишком быстро "протухают"? Что вообще происходит тогда с тестовой сборкой?
У нас есть боевой пул пользователей и аналогично тестовый, только тестовый пул намного больше. Вы правы, так как схемы пересоздаются циклично и размер пула ограничен, то через какое-то время более новая сборка получает более ранний порядковый номер, тем самым обновляя информацию в журнале сборок. Ветка, которая «протухла» (отдала свою схему более новой сборке) лечится путем пересборки.
НЛО прилетело и опубликовало эту надпись здесь
Подскажите, а как вы решили, и решали ли следующую ситуацию: имеем команды А и Б пилящие соотв продукты, мигратор то общий — как им быть с деплоем своих фич? В нашем случае мы пришли к выводу что проще каждой команде развернуть свой тестовый сервер
У всех наших разработчиков есть возможность развернуть локально dev окружение в контейнере, в котором они могуть вести разработку и деплоить код всеми доступными способами. Миграции проверяются командой DBA и мержатся для дальнейшего нагрузочного тестирования.
Вероятно вы держите некий слепок «мини» базы, повторяющий продуктовую но имеющий ограниченный набор данных? Подскажите как вы его строите — забираете бекап и урезаете данные или у вас изначально была пустая база и скрипты для ее наполнения?
У нас есть собственный инструмент для семплирования и фикстуры для того, чтобы проводить тестирование нашего приложения. После семплирования данных мы готовим докер-образ, который пушим в наше облако. Из образа поднимаются базы, dev и test среда и другая инфраструктура (внешние индексы, различные кэши, очереди). На семпловых данных поднимается вся связанная инфраструктура. Таким образом, применение семпловых данных приводит к инициализации около десятка баз данных.
Если не серкерт, каков объем тестовой базы и как долго строиться ее образ?
30 минут, 5 GB.
Если мигратор общий на все комманды, то возможна ситуация когда изменения в миграторе обоих комманд уже приехали на прод, но еще не приехали сами приложеньки эти изменения использующие, интересно как вы решили подобную штуку, просто коммуникацией между командами, или быть может приложения выкатывают вообще в переди мигратора или быть може еще какой вариант, интересно как в целом вы построили процесс деплоя
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Версионирование и деплой кода PostgreSQL