Насколько круто пользовательские типы данных в SQL Server? [закрыто]

Question

Являются ли определяемые пользователем типы данных в SQL Server чем-то, что средний пользователь SQL должен знать и использовать?

Каковы плюсы и минусы использования UDT?

Answer 1

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

Проверьте этот вопрос для деталей: Как изменить базовый тип UDT в Sql Server 2005?

Answer 2

Я не использую UDT на основе кода, потому что я не думаю, что дополнительная сложность гарантирует преимущества. Я делаю использую UDT T-SQL, потому что дополнительная сложность очень мала, поэтому преимущества стоят усилий. (Спасибо Marc_s за указание на то, что мой оригинальный пост был неполным!)

Об основанных на коде UDT

Подумайте об этом так: если ваш проект имеет компонент управляемого кода (ваше приложение) и компонент базы данных (SQL Server), какое реальное преимущество вы получаете от определения управляемого кода в базе данных? По моему опыту? Отсутствуют.

Развертывание более сложное, потому что вам придется добавлять сборки в вашу базу данных и изменять эти сборки, добавлять файлы и т. д. в SQL Server. Вам также нужно будет включить CLR в SQL Server (не так уж и сложно, но никто не доказал мне, что это не приведет к снижению производительности / памяти). В конце концов, вы получите именно то, что получили бы, если бы просто встроили это в код своего приложения. Может быть некоторое улучшение производительности, но это действительно поражает меня как случай преждевременной оптимизации - тем более, что я не знаю, страдает ли общая производительность из-за того, что CLR включен или выключен.

Примечание. Я предполагаю, что вы будете использовать CLR SQL Server для определения ваших типов. HLGEM говорит о SQL Server 2000, но я не знаком с 2000-м и думал, что он имеет только UDF, а не UDT в внешне определенных dll (но не цитируйте меня ... Я действительно не знаком с ним!).

Что касается UDT T-SQL

UDT T_SQL можно определить только в SQL (см. " Программируемость | Типы | Определяемые пользователем типы данных &; в SQL Server Management Studio). Для стандартных UDT я хотел бы порекомендовать вам освоить их. Они довольно просты и могут сделать ваш DDL более самодокументированным и могут обеспечить ограничения целостности. Например, я определяю & Quot; GenderType & Quot; (char (1), не обнуляемый, содержит " M " или " F "), который гарантирует, что в поле Gender разрешены только соответствующие данные.

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

Когда я первоначально ответил на этот вопрос, я сосредоточился на идее сложных, определенных в коде типов ( хлопает ладонью по лбу ). Так что ... спасибо Марк.

Answer 3

Профессионал пользовательских типов адресован довольно хорошо Алекс Пападимулис. Минусы были хорошо изложены здесь.

Я также хотел бы отметить, что функция sp_bindrule устарела, как отмечается в сообщении Алекса. Я не уверен, когда это устарело, но сейчас. На самом деле, правила устарели в целом.

Если бы я хотел создать тип с ограничением, я бы подумал об использовании определяемого пользователем типа таблицы с проверочным ограничением на соответствующие столбцы. Это также дает мне способ создания сложного типа данных.

Answer 4

Я не могу порекомендовать использовать какие-либо специфические особенности реализации SQL, которые усложняют ситуацию, когда вы вырастаете из mssql и переходите на другую базу данных. Для наших dwh dbs мы начали с mssql, перешли на oracle и с прошлого года перешли на hp vertica.