Comments 14
Для упрощение будущего кода на CI был введен стандарт именования: scheme.Name.Type.sql
А почему не scheme.Type.Name.sql ?
На самом деле можно и так, я не думаю что была бы какая то проблема, просто при парсинге имени и откидывании расширение sql работали как будто Procedure или Viwe - это расширение(формат объекта). До этого был опыт с парсингом файлов где как раз расширение определяло как паристь файл, и ход мысли пошел в эту сторону
Да, сиквел и контроль версий это боль. Особенно если не code first.
Мы пока сделали серверный триггер, который на все ddl пишет в табличку кто, какой объект , когда, ну и сам текст ddl.
Не гит конечно, но зато абсолютно прозрачно и универсально.
Можно пойти дальше и эти логи собирать в виде файлов и привести к тому, что получилось у вас.
Да, сиквел и контроль версий это боль - абсолютно с Вами согласен. Нам хотелось не менять Git flow и пустить все по накатанному и нужно было легкое ревью, сталкивались с проблемами не понятного расставленных алиасов и после этого SQL становится абсолютно не читаем. Но мне кажется все зависит от потребностей. Любое решение это лучше чем поднимать бэкап и искать что изменилось.
Oracle и контроль версий - вот где настоящая боль.
Сделал аналогично. Кроме того весь ddl код под контролем. В том числе и прописывание юзеров и создание ролей
Мне лично не приходилось версионизировать MSSQL пообъектно, но мне коллеги БД-шники показывали, что для пообъектного хранения БД есть:
Для SQL Server - MS продвигает стандарт DACPAC + набор инструментов SSDT чтобы это генерить и раскатывать.
Вроде решает вашу задачу. Не пробовали?
Для дугих БД (postgres) вроде еще есть sqitch, которым можно что-то похожее делать
Для SQL Server - MS продвигает стандарт DACPAC + набор инструментов SSDT - изучали, но не пробовали, на самом деле не нашли(может плохо искали) как легко проводить ревью кода, одной из задач было стандартизировать SQL и убрать ужасный code style второй проводить двойной code review что бы не за деплоить на сервер лишние ошибки, которых можно было избежать. Спасибо что напомнили, в данный момент острой необходимости что то менять нет(все пока работает хорошо и нас устраивает) можно развернуть песочницу и поэкспериментировать возможно в будущем и перейдет на данный стандарт!
dacpac создаётся из DB проекта(*.sqlproj файл) который выглядит как обычный C# проект в солюшине. И ревьювить его можно как и все остальные проекты, каждый объект(хранимая процедура, таблица и тд) в этом проекте это отдельный файл, как и в вашем решении.
Дополнительно при накатке dacpac-a можно настроить, чтоб он следил за тем, чтоб у базы не было объектов которые не входят в проект, что тоже довольно полезно, вы всегда уверены что база всегда выглядит именно так, как у вас в коде.
У нас на проекте все базы деплоятся только через dacpac и все работает как часы, код реаьювается и всегда версионируется
Если есть скрипты, которые только для прода, то почему и не держать их непосредственно в продовой ветке, а в стейджинг не совать? Маркер можно оставить сугубо для разработчиков, а отдельно кодить поведение не придётся.
Можно использовать триггер БД и событие event где весь код ddl прослеживается вплоть до создания юзеров и назначения ролей, логины, ip адреса, наименования хвостов и тп все можно записывать в таблицу (или таблицы по типу ddl) отдельной БД, кто, что и когда менял. Из таблиц все записи можно получить как вам удобно. Самый простой вариант источник данных в excell, куда можно отображать список объектов из таблиц.
Как я реализовал git-flow для SQL