генерация скриптов для БД

Одним из наиболее любимых путей замены программирования на динамическом sql для разработчиков кода является автоматическая генерация скрипта для БД при помощи среды разработки типа Csharp.

Оправданы ли затраты такого пути?

Большой плюс такого подхода в том, что зависимый от макроподстановок sql скрипт формируется в виде нормального текста, к которому можно применять оптимизацию и упрощает отладку кода скрипта.

Большой минус в том, что надо изучить среду и создать свое приложение генерации кода. Это все было бы не так страшно, если бы не перестройка мозгов. Программист на csharp мыслит ортонормально с программистом на sql. Может это и лирика, но мою голову клинит еще почище, чем, когда программировал на динамическом sql.

Forums: 

Изображение пользователя st.

А зачем C# и Visual Studio? Я

А зачем C# и Visual Studio? Я генерировал код из процедур на самом же Transact SQL.

Изображение пользователя ipanshin.

А зачем C# и Visua

А зачем C# и Visual Studio?

Я тоже думал, что надо генерировать код на самом sql. Но... Меня поправили (я же в группе сейчас программирую) и сказали, что sql не предназначен для таких целей. А сишарп создан именно для этого. То есть налицо подход со второстепенной ролью БД.

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

Минус этого, в той же ненагруженности процедур. Исчезает анализ из БД и как следствие БД превращается в простое хранилище.

Видимо, истина лежит гдето посредине.

Изображение пользователя st.

А заче

А зачем C# и Visual Studio?

Я тоже думал, что надо генерировать код на самом sql. Но... Меня поправили (я же в группе сейчас программирую) и сказали, что sql не предназначен для таких целей. А сишарп создан именно для этого. То есть налицо подход со второстепенной ролью БД.

SQL не предназначен, а Transact SQL предназначен и для этого. Особенно в версии 2005, где он приобрел очередные новые возможности полноценного процедурного языка.
Товарищи возможно, просто недостаточно хорошо владеют инструментом.

Изображение пользователя ipanshin.

хорошо владеют инс

хорошо владеют инструментом.

Никого не желаю переубеждать. В 2005 много чего наворочено. Скажем имя процедуры есть, а самой ее нет, или выполняется только к контексте БД мастер и только из определенной ХП. Кстати механизм репликаций отлажен, но применим может быть к своим объектам только, если осилишь задачу соответствия объектов БД к своим классам объектов. Частная задача полиморфизма классов своих в реплицируемые объекты БД. А это не так просто как оказывается.

Изображение пользователя ipanshin.

А это не так прост

А это не так просто как оказывается.

Сегодня заработала коллекторная схема репликации. Я ее называю так потому, что одна из баз данных представляет собой коллектор, т.е. в нее входят несколько стрелок реплицируемых данных из других БД. Все, участвующие в репликации таблицы, объединяет одно вью, которое консолидирует данные в рамках приложения. Жесткую схему такого можно просто построить, но какая головная боль возникает, когда мы в динамике перестраиваем публикации, учитывая, естественно отображение своих классов объектов на объекты БД, участвующие в репликации.

Результат понятен.
Указываешь какие объекты своего класса подлежат репликации и они публикуются и реплицируются в соответсвии со схемой головной оффис(коллектор) и несколько филиалов - подписчиков.

Эх, почему куски Родины покупают у некоторых,
А мой код нет?