Рефакторинг в SQL

[vlad]

Раз уж пошла такая пьянка (про SQL)...

Рефакторинг, наверное, даже слишком громко сказано (alexus сразу начнет говорить "ибо нефиг")....
Просто. Была колонка CHAR(100). Стало мало. Надо сделать CHAR(255). Речь, естественно, не только о модификации таблицы, но и о модификации всяких триггеров и хранимых процедур. Их не очень много, но искать их (имеющих отношение к данной таблице) и в них нужное крайне трудоемко (по сравнению с традиционными статически типизированными языками). Что нужно делать, чтобы такие простые вещи не требовали столько усилий?

P.S. Применительно к M$ SQL. Я знаю, что в интербейзе было что-то типа typedef'ов. Не знаю насколько они полезны там, но в M$ SQL они тоже есть и они абсолютно бесполезны (для описанной проблемы).
P.S.S. Считаю SQL (как язык) полным говном. Не хотелось бы выплескивать негатив, но SQL мне кажется крайне неудачным языком для чего-либо кроме SELECT.

[Valery Solovey]

А триггеры и хранимые процедуры - это SQL?

[vlad]

А триггеры и хранимые процедуры - это SQL?

Я знаю, что у разных СУБД свои "языки хранимых процедур", но тем не менее, они пытаются выглядеть похожими на обычный SQL. Не вижу смысла здесь что-то противопоставлять (если только ты не считаешь это важным для решение сабжевой проблемы).

[ilovb]

Я напрямую с СУБД не работаю, потому про рефакторинг ничего не скажу.
1С всю реструктуризацию при внесении изменений делает автоматически, там это возможно т.к. приложение абстрагировано от уровня таблиц. Тоже выход в принципе, если вы готовы пожертвовать гибкостью немного 

А SQL да дрянь... даже SELECT...

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

[vlad]

Я напрямую с СУБД не работаю, потому про рефакторинг ничего не скажу.
1С всю реструктуризацию при внесении изменений делает автоматически, там это возможно т.к. приложение абстрагировано от уровня таблиц. Тоже выход в принципе, если вы готовы пожертвовать гибкостью немного 

Т.е., общий ответ - ORM?

[ilovb]

О! Вот как оказывается архитектура 1С называется 
Не знал, что этому подходу есть название.

Ну примерно так... да.

[Peter Almazov]

Раз уж пошла такая пьянка (про SQL)...

Рефакторинг, наверное, даже слишком громко сказано (alexus сразу начнет говорить "ибо нефиг")....
Просто. Была колонка CHAR(100). Стало мало. Надо сделать CHAR(255). Речь, естественно, не только о модификации таблицы, но и о модификации всяких триггеров и хранимых процедур. Их не очень много, но искать их (имеющих отношение к данной таблице) и в них нужное крайне трудоемко (по сравнению с традиционными статически типизированными языками). Что нужно делать, чтобы такие простые вещи не требовали столько усилий?

P.S. Применительно к M$ SQL. Я знаю, что в интербейзе было что-то типа typedef'ов. Не знаю насколько они полезны там, но в M$ SQL они тоже есть и они абсолютно бесполезны (для описанной проблемы).
P.S.S. Считаю SQL (как язык) полным говном. Не хотелось бы выплескивать негатив, но SQL мне кажется крайне неудачным языком для чего-либо кроме SELECT.

А зачем модифицировать триггеры и хранимые процедуру при изменении ширины колонки? Это ж как надо извратиться при написании тригера, чтобы в нем явно фигурировал размер колонки. Неужели имеет место?

Полное говно - это, видимо, про TRANSACT-SQL 

[DIzer]

Vlad - обычно в том случае, когда есть подозрение на то, что будут изменятся поля (типы, размеры)  - используются домены (DOMAIN) - еще 10 лет назад  любая уважающая себя sql СУБД - поддерживала работу с ними... ВСЕ изменения шли с помощью одного  запроса вида ALTER DOMAIN DNAME SET....

[vlad]

А зачем модифицировать триггеры и хранимые процедуру при изменении ширины колонки? Это ж как надо извратиться при написании тригера, чтобы в нем явно фигурировал размер колонки. Неужели имеет место?

Дык, об чем и речь. Как? Например, как завести переменную (куда временно будет складываться что-то) размером с размер колонки? Никто бы не писал "DECLARE @var CHAR(100)" если бы можно было сослаться на тип колонки.

Полное говно - это, видимо, про TRANSACT-SQL 

Да, видимо.

[DIzer]

ЧУШЬ 

[DIzer]

На вопрос конкретно  как - ответ в руководстве по диалекту SQL соответствующей СУБД -  в разделах DDL (язык определения данных - для синтаксиса определения домена, и его изменения) Разумеется таблицы ДОЛЖНЫ быть созданы с использование доменов а не базовых типов...

[vlad]

Vlad - обычно в том случае, когда есть подозрение на то, что будут изменятся поля (типы, размеры)  - используются домены (DOMAIN) - еще 10 лет назад  любая уважающая себя sql СУБД - поддерживала работу с ними... ВСЕ изменения шли с помощью одного  запроса вида ALTER DOMAIN DNAME SET....

Видимо MS SQL не относится к "уважающим себя"

[vlad]

На вопрос конкретно  как - ответ в руководстве по диалекту SQL соответствующей СУБД -  в разделах DDL (язык определения данных - для синтаксиса определения домена, и его изменения)

Я ж говорю - не работает оно. Помню было у нас так поле объявлено через DDL - огребли больше, чем если бы ручками надо было искать CHAR(100). Подробностей сейчас не помню, но это было что-то из серии хардкорного ковыряния в системных таблицах и пересоздания всех хранимых процедур, в которых эта херня исользовалась. С тех пор было решено этой штукой не пользоваться никогда

[DIzer]

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

[vlad]

На вопрос конкретно  как - ответ в руководстве по диалекту SQL соответствующей СУБД -  в разделах DDL (язык определения данных - для синтаксиса определения домена, и его изменения) Разумеется таблицы ДОЛЖНЫ быть созданы с использование доменов а не базовых типов...

Есть подозрение, что мы говорим о разных вещах, поэтому давайте конкретизирую:
Итак, MS SQL2005 и выше. Как объявить колонку в таблице, чтобы потом безболезненно ее расширять? Как ссылаться на тип этой колонки в хранимых процедурах и триггерах? Как, собственно, потому менять этот тип? Сразу оговорюсь, что пересоздание (ручное) всех процедур/триггеров не катит - нет полного контроля над базой (юзера могут сами туда чего-то добавлять/менять).