Есть композитное приложение в разработке, где каждый компонент имеет свои объекты БД (или отдельную БД) + определенную последовательность выполнения sql файлов (у некоторых нужно сначало сгенерить sql для секьюрити (статические права, роли) и т.п., а только потом выполнять файлы sql).
Все компоненты лежат в отдельных папках, файлы и(или) папки с файлами иногда должны выполнятся в строго указанной последовательности.
В тексте sql есть placeholders, куда нужно вставлять значения, задаваемые на самом высоком уровне (например название схемы, куда лить объекты или БД куда подключаться).
Некоторые компоненты не должны входить в "сборку" по признаку, который также указывается на верху. Чтобы можно было генерить БД только для нужного функционала.

Вопрос: есть ли тулза, где:
*) можно создать проекты для каждого такого компонента.
*) проект должен поддерживать включение как отдельного файла, так и папки, другого подпроекта, куска голого SQL прямо в файле проекта. Состав файлов папки может быть жестко указан или просто *.sql.
*) каждый проект должен задавать строгую последовательность выполнения sql файлов
*) поддерживается динамическая замена части sql на указанное значение. Т.е. поддерживаются переменные проекта.
*) каждый такой проект и каждую его часть (включаемый файл/папку) можно было отключить по признаку (переменная?).

Кто чем пользуется для воссоздания БД при девелопменте, когда у каждого разработчика должны быть своя копия БД?

А что такое пре компайлер и как он поможет, если у меня пачка sql-файлов?

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

Локальную БД каждый дев. ведет для уменьшения взаимных блокировок и багов при разработке. Каждый варится в своей БД до выполнения задачи, а потом сливает изменения+код в СВН. В итоге работа идет в разы быстрее одной БД на всех.

Ах да, забыл: нужна поддержка MSSQL & Postgres как минимум.

авторТолько непонятна цель, вы её не озвучили, только "просто хочется". Почему всё-таки для девелоперских локальных баз не использовать восстановление из бакапа?

потому что бекап нужно еще сделать, а есть только набор sql-файлов в СВН для создания БД с нуля + очень динамичная разработка. Т.е. Петя ждет пока Вася доделает фичу1, потому что фича2 зависит от нее. Как только Вася закомитил фичу1 в СВН, Петя забирает изменения Васи и пересобирает у себя БД для фичи2. Это очень быстро, а бекап (для восстановления из) нужно еще ждать.

авторПросто разработчики на локальных базах будут отходить от правил процесса разработки и деплоя, в результате базы будут отличаться от той, которая в проекте.

хм, с чего бы это они будут отходить от правил и базы будут отличаться? К тому же деплой разработчики не делают, их это не касается. Их дело залить новый код БД + процедуры миграции, если была модификация БД, по которому потом будет составлен дифф БД для накатки у клиента.

авторУдобнее, чтобы девелоперская база обновлялась ежесуточным (например) билдом и деплоем, а к себе локально разработчики получали её из бакапа.

Мы пробовали вариант 1 база много девов - результат жуть в плане взаимоблокировок и багов из-за накладывающихся изменений двух и более девов на один объект БД. +резолвить конфликты СВН, если на измененный код одного дева перезалили уже десять раз код другие - то еще удовольствие.
Также вариант с блокированием файла на время редактирования не подходит, т.к. тормозит других.

авторДа можно и так, только я повторюсь - никто так не делает.

как минимум это делаем мы и нам так удобнее/надежнее.

авторНе вижу, почему работа должна идти быстрее в разы :-) Неужели только из за блокировок и багов? Вроде и так ничего не мешает, люди же работают над разными задачами.


Именно из-за блокировок и багов родимых. Представьте проект 100+ проектов с солюшине в которых процентов 20 - отдельные подпроекты баз + девелоперы не узкоспециализированные, т.е. прав все всё, т.е. "люди же работают над разными задачами" в 99% нет, задачи пересекаются функционалом почти всегда.

Но суть не в этом. Хочеться задать xml-ем порядок выполнения скриптов и пнуть консольку какую нибудь. Неужто никто такого не делал?

авторЯ же вам назвал инструмент.

у нас есть почти такие костыли, не подходит. Надо что-то универсальное, у которого достаточно поправить пару конфиг файлов, если исходные файлы перенесли или добавили.

авторНу, если нужно ТАК быстро, если роль играют часы, минуты, тогда да :-)

так так у всех, нет!? На таск есть время, часто в часах, и будь добр вложиться.

авторНу, просто в графической утилите что-то в базе поправят, вне проекта, мало-ли. Обычно так бывает.

как раз с локальными базами у каждого дева это не проблема. У нас БД правится в Manag Studio, потом тулза генерит исходники нужных объектов БД в файлы, которые девы заливают в СВН. Т.е. дев может править БД хоть через sqlcmd, ничего это не нарушит/изменит.

авторИзменение базы (например, своей локальной) называется деплоем.

у нас деплой, это поставка версии клиенту, т.ч. мы говорим о разных процессах.

авторЭто вы про файл, например, объекта? То есть интенсивность разработки настолько высока, что нужно обеспечить изменение структуры одной таблицы одновременно несколькими разработчиками, и потом автоматически мержить изменения? Круто!

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

зы: что-то мы скатились в оффтоп, пойду гуглить, может повезет...