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

[DIzer]

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

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

Ответ для  MS SQL2005 никак - просто эта фича, которая есть в стандарте аж 92 года не поддерживается , для других СУБД как я  описал...  результат выполнения запроса на изменения домена зависит от конкретной субд -  в DB2 например у меня  было изменена структура  несколько таблиц, конвертированы данные но после того, как я переправил несколько процедур и триггеров (то есть  пришлось делать запрос несколько раз - после неудачи выдавались зависимости мешающие его выполнению).

[Valery Solovey]

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

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

Но похожесть на SQL не делает их SQL-ом (или делает? я не читал стандарт). А SQL - полным говном.

А единственное решение, приходящее мне в голову - не править БД вручную. Делать это через инструмент. Некий графический интерфейс. Правим какое-то поле, и изменения вносятся как в таблицы, так и в хранимые. Это всё. Чего-то более конкретного подсказать не могу. И более простого - тоже.

[DIzer]

А единственное решение, приходящее мне в голову - не править БД вручную. Делать это через инструмент. Некий графический интерфейс. Правим какое-то поле, и изменения вносятся как в таблицы, так и в хранимые. Это всё. Чего-то более конкретного подсказать не могу. И более простого - тоже.

А практически все нормальный "инструменты"используют для правок БД либо SQL  либо функции официального API - так что разница такая же как при работе с файлами  через файловый менеджер vs командной  строкой.  Если необходимо разрешить конкретную ситуацию (а не рассуждать как в нее не попадать и какие есть средства в стандартном SQL, и говно он или нет  )  например как у Влада то порядок  возможных действий через SQL
1. Создать нужное временное поле в таблице ALTER TABLE....
2. Скопировать туда данные из изменяемого поля
3. Пробовать уничтожить ненужное поле - БД это не даст, пока есть зависимости (в триггерах, индексах....) которые она выдает в сообщениях - эти зависимости нужно разрешать (либо деактивировать триггеры, индексы.. если это возможно),
4. После того как зависимости разрешены а поле уничтожено, поменять название нового поля на старое
5 Активировать триггеры , построить (перестороить) индексы....
Это  общий план для любой SQL Cубд- конкретика зависит от возможностей той СУБД в которой эти манипуляции производятся и структуры и зависимостей  рассматриваемой таблицы (например, может быть просто достаточно изменить исходное поле)

[Valery Solovey]

 Самое главное-то я и забыл сказать...
Поскольку, нужного инструмента не существует, то его нужно написать самому. Вот тут-то и появляются неприятные ощущения.

А практически все нормальный "инструменты"используют для правок БД либо SQL  либо функции официального API - так что разница такая же как при работе с файлами  через файловый менеджер vs командной  строкой. 

Может, аналогия с файловым менеджером и применима, но если я правильно понял Влада, то у него вполне определённая проблема, которую можно решить внешним инструментом (если такая возможность отсутствует в SQL).

Например, есть две таблицы. В одной имеются реквизиты владельцев, а в другой - реквизиты счёта. Целостность данных помогает поддерживать внешний ключ. Например, удаления в таблице владельцев запустят удаления в таблице счетов. То есть, в SQL есть механизм привязывания к ресурсу. Все, кто привязались к данному ресурсу, реагируют на определённые события.

Проблема Влада, если я её правильно понял, заключается в том, что в SQL нет адекватного механизма, привязывающего триггеры и хранимые к некоторым ресурсам. Инструмент, связывающий две таблицы - это внешний ключ, а инструмента, привязывающего действия к типам данных, нет. Решение - сделать инструмент, хранящий всю схему БД внутри себя и дополняющий её своими правилами. Если выполнять изменения БД через инструмент, то в СУБД будут передаваться команды вроде тех, которые Вы привели выше.

[DIzer]

Самое главное-то я и забыл сказать...
Поскольку, нужного инструмента не существует, то его нужно написать самому. Вот тут-то и появляются неприятные ощущения.
.....

  Как это не существует ? Стандартная консоль (аналог cmd) есть практически  во всех SQL СУБД, Гуйный мэнагер в MSSQL изначально был одним из лучших...
  А насчет неприятных ощущений... они возникают всегда, когда не понимаешь задачу и/или не знаешь как ее решить... и без разницы что это.

[DIzer]

Про сторонние мэнагеры как общего плана, так с заточкой под MSSQL , бесплатные и не очень даже не говорю...

[DIzer]

Это болезнь СИ шников  лезть в СИСТЕМНЫЕ таблицы и править там  что -то ни х. не понимая ВСЕХ последствий - (дело в том, что информация в этих таблицах МОЖЕТ отображаться точно также  как и в обычных (и даже иметь сходную структуру), но из этого не следует что в общем случае ОБРАБАТЫВАТЬСЯ  она будет также), правда есть исключения - системные таблицы, домены...  в DB2 - обрабатываются обычными SQL -запросами.

[Valery Solovey]

Самое главное-то я и забыл сказать...
Поскольку, нужного инструмента не существует, то его нужно написать самому. Вот тут-то и появляются неприятные ощущения.
.....

  Как это не существует ? Стандартная консоль (аналог cmd) есть практически  во всех SQL СУБД

То есть, Вы хотите сказать, что консоль найдёт мне, какие элементы связаны с данным ресурсом? Хотя бы найдёт. Поменять я поменяю вручную, но ковыряться во всей схеме БД, чтобы найти пять или сем хранимок - это то ещё удовольствие.

[DIzer]

Самое главное-то я и забыл сказать...
Поскольку, нужного инструмента не существует, то его нужно написать самому. Вот тут-то и появляются неприятные ощущения.
.....

  Как это не существует ? Стандартная консоль (аналог cmd) есть практически  во всех SQL СУБД

То есть, Вы хотите сказать, что консоль найдёт мне, какие элементы связаны с данным ресурсом? Хотя бы найдёт. Поменять я поменяю вручную, но ковыряться во всей схеме БД, чтобы найти пять или сем хранимок - это то ещё удовольствие.

  Хочу - некоторые СУБД поддерживают команды возвращающие  зависимости по обьекту... а если нет, или  вы ленивы и/или не умеете работать с документацией- то ход действий я описал - пытаетесь уничтожить поле ПОСЛЕ того как сохранили информацию в поле НУЖНОЙ структуры (каждая НЕУДАВШАЯСЯ попытка вскрывает зависимости).
Да разумеется - этот выход НЕ ДЛЯ  квалифицированных специалистов - те работают СТРОГО по принципу - выявил зависимости, выбрал ОПТИМАЛЬНЫЙ порядок  действий, выполнил их.

[DIzer]

Конечно "сохранили информацию в поле НУЖНОЙ структуры" - не грамотно сказано... речь идет о сохранении данных (записей).

[alexus]

Может, аналогия с файловым менеджером и применима, но если я правильно понял Влада, то у него вполне определённая проблема, которую можно решить внешним инструментом (если такая возможность отсутствует в SQL).

Например, есть две таблицы. В одной имеются реквизиты владельцев, а в другой - реквизиты счёта. Целостность данных помогает поддерживать внешний ключ. Например, удаления в таблице владельцев запустят удаления в таблице счетов. То есть, в SQL есть механизм привязывания к ресурсу. Все, кто привязались к данному ресурсу, реагируют на определённые события.

SQL накладывает требования на язык, но он не регламентирует структуру метаданных и работу с ними (см. например). Это остаётся в руках разработчиков СУБД. И это правильное решение. Стандартизация хороша до определённого момента. В ЯВУ тоже стандарты языков не распространяются на реализацию компиляторов, линкеров, мапперов и пр.
Далее, если к каким-то объектам БД (таблицам, представлениям (view), процедурам или триггерам, ...) происходит обращение от других объектов БД, то эти связи хранятся в метаданных. При удалении, например, поля таблицы СУБД должна либо отказать в удалении, либо предупредить, что связи с другими объектами будут разорваны, что чревато неприятными последствиями.

Проблема Влада, если я её правильно понял, заключается в том, что в SQL нет адекватного механизма, привязывающего триггеры и хранимые к некоторым ресурсам. Инструмент, связывающий две таблицы - это внешний ключ, а инструмента, привязывающего действия к типам данных, нет. Решение - сделать инструмент, хранящий всю схему БД внутри себя и дополняющий её своими правилами. Если выполнять изменения БД через инструмент, то в СУБД будут передаваться команды вроде тех, которые Вы привели выше.

Проблемы Влада, если я их правильно понял... совсем в другом... Правда, он уже начал читать, может быть начнёт думать, а если ещё и практику приложит, то есть шанс, что... проблемы, о которых он пытался рассказать, уйдут сами собой...

[vlad]

Проблемы Влада, если я их правильно понял... совсем в другом... Правда, он уже начал читать, может быть начнёт думать, а если ещё и практику приложит, то есть шанс, что... проблемы, о которых он пытался рассказать, уйдут сами собой...

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

Из общих выводов у меня пока сформировался такой: SQL - это ассемблер. Говорить, что он говно - неконструктивно, надо просто на нем не писать 

[DIzer]

Забавно, с чего бы это? у меня противоположное.. -  по мне так SQL высокоуровневый ЯП для определения структур , их модификации, а также работы с данными (усвоил идеологию и вперед)- а вот работа через  API с БД напрямую- кака -бяка которой нужно избегать (уровень знаний НЕОБХОДИМЫЙ для выполнения СЛОЖНЫХ действий неизмеримо выше)  - ваш пример с модификациями системных таблиц хорошая иллюстрация тому....

[DIzer]

2Valexey   SELECT DISTINCT FIELDNAME FROM TABLENAME   (здесь  FIELDNAME,TABLENAME название фактических поля и таблицы - для большинства диалектов SQL (но могут быть исключения - нужно смотреть сверится с руководством SQL конкретной базы в разделе DML (DATA MANIPULATION  LANGUAGE) ) )

[valexey]

2Valexey   SELECT DISTINCT FIELDNAME FROM TABLENAME   (здесь  FIELDNAME,TABLENAME название фактических поля и таблицы - для большинства диалектов SQL (но могут быть исключения - нужно смотреть сверится с руководством SQL конкретной базы в разделе DML (DATA MANIPULATION  LANGUAGE) ) )

Угу. Спасибо.