GlorytrewА было бы удобно, если бы такая возможность была.
Ага.
Мы сделали сначала поле varchar(max) для хранения даты-времени
Потом решили поменять его на datetime
Хорошо бы было, если бы сервер сам сконвертировал все данные из одного типа в другой.

Тут и сказке конец.Да в общем в этом ничего невероятного нету.

Можно пытаться конвертить по умолчанию, можно ограничиться только родственными типами (например, менять date на datetime), можно к конструкции ALTER TYPE добавить выражения приведения данных при изменении типов.

То есть это не то, что теоретически невозможно, просто МС увлекается всякими CLR и не увлекается совершенствованием реляционного ядра :-)

GloryalexeyvgТо есть это не то, что теоретически невозможно, просто МС увлекается всякими CLR и не увлекается совершенствованием реляционного ядра :-)
Мне кажется, что правильное проектирование схемы не является функцией ядра.Это не проектирование, а изменение модели данных.
Модель данных в MSSQL менять допускается, например, для таблиц разрешены ALTER TABLE, можно менять, удалять, добавлять колонки.

Я, честно говоря, не вижу разницы в изменении типа так, как я описал выше, и том же самом изменении, сделанном непоследственно в таблице.
Гость333alexeyvgнапример, менять date на datetime
То есть поменять 3-байтовый тип данных на 8-байтовый? Как это должно выглядеть для той же таблицы на 100 млн. записей? :-)Да в общем не так это сложно, учитывая, что это можно делать не немедленно. Но это так, лирическое отступление.

Уж точно это не сложнее (и не проще), чем поменять date на datetime непосредственно в таблице, что сейчас разрешено (и было разрешено всегда). То есть просто думать надо перед выполнением таких действий, но тем не менее потенциальная длительность изменений и ресурсы, которые на это потребуются, не повод не делать такую функциональность или запрещать существующую (ALTER TABLE).

GloryalexeyvgДа в общем не так это сложно, учитывая, что это можно делать не немедленно. Но это так, лирическое отступление.

Уж точно это не сложнее (и не проще), чем поменять date на datetime непосредственно в таблице, что сейчас разрешено (и было разрешено всегда). То есть просто думать надо перед выполнением таких действий, но тем не менее потенциальная длительность изменений и ресурсы, которые на это потребуются, не повод не делать такую функциональность или запрещать существующую (ALTER TABLE).
Предположим, что у меня 1 тип использован в 100 таблицах.
Что будет, если в 99 таблицах автоматическая смена типа пройдет удачно, а в 100ой обломится ?
Кто будет отвечать за логическую целостность ?
Если ядро, то оно сможет сделать это только через транзакцию.Да, через транзакцию.

Как можно решить эту же бизнес-задачу сейчас? Открыть транзакцию, и сделать 100 раз ALTER TABLE для этих таблиц.

Так что в общем то же самое. Но конечно вариант без "типа" более гибкий - я могу делать эти же операции частями, забив на целостность, управляя целостностью вручную и полностью забив на атомарность этой операции.

Соответственно, можно было бы предусмотреть в варианте ALTER TYPE 2 режима - атомарный и не атомарный. В первом случае операция выполяется или не выполняется целиком, откатываясь после первой же ошибки, во втором выполняется для тех таблиц, где это получилось, возвращая ошибки.

Ну и понятно, изменение модели - исключительный случай, нужно будет предусматривать "окно" для изменений, общем не такое простое дело.

С другой стороны, есть масса случаев, когда на такой операции не может произойти ошибок, кроме общесистемных (например, кончилось место).

Кроме того, для таких операций (где не может произойти ошибок, кроме общесистемных) МС часто предусматривает асинхронное выполнение.
Возьмите к примеру добавление NULL поля в таблицу - это даже для большой таблицы выполняется моментально, потому что физическое изменение страницы откладывается на момент изменения страницы какой либо обновляющей операцией.
Вот и здесь - при изменении "типа" в некоторых случаях можно использовать этот режим. Например, менять varchar(100) на varchar(200) или varchar(100) на nvarchar(100) можно соверешнно безопасно в отложенном режиме, так что для 100 огромных таблиц это займёт милисекунды.

GloryДаже ALTER TABLE не позволяет изменять тип и размерность поля, например, для поля
Used in a PRIMARY KEY or [FOREIGN KEY] REFERENCES constraint.
и еще куча ограниченийДа, ALTER TABLE не позволяет, так идея в том, чтобы для ALTER TYPE позволяло, ведь тип будет изменён везде, так что REFERENCES constraint не пострадают.
GloryЕсли ввести еще ваши ограничения, то по-моему останется только такие изменения, которые затрагивают только метаданные, а не сами данные
Т.е. varchar(100) на varchar(200) . А вот varchar(200) на varchar(100) - уже нетДа в общем разные могут быть подходы; по крайней мере это тема для обсуждения, ИМХО не такая плохая идея.

По крайней мере, в транзакции всё можно поменять, хоть метаданные, хоть данные... Т.е. ограничения касаются только выбора механизма изменений типа, быстрый или медленный.
MniorТ.к. уже у таблиц есть несколько внутренних описаний структуры (версий) и в страницах хранится код структуры (версии).
То также сделать в типах, и версиях таблиц прописывать не тип, а его версию.Да, я собственно это и имел в виду. Такой способ, понятно, годится только для безусловно совместимых изменений, но это уже что то, можно будет хоть int на bigint поменять быстро, без ожиданий...

MnioralexeyvgДа, я собственно это и имел в виду.Вы думаете мы всё продумали и можем уже предлагать MS?
Мне кажется мы возможно не учли какой-то логичной фишки, которая не лежит на поверхности, но мешает это сделать.
Надо искать подводные камни.Думаю, всё учли :-)

https://connect.microsoft.com/SQLServer/feedback/details/319134/msft-mso-support-alter-type