SQL Serverのユーザー定義データ型はどれほどクールですか？ [閉まっている]

Question

SQL Serverのユーザー定義データ型は、中間SQLユーザーが知って使用する必要のあるものですか？

UDTを使用する場合の長所と短所は何ですか？

Answer 1

それらを決して使用しないでください。定義を変更する必要がある場合、あなたは怪我の世界にいます。おそらくこれは、SQL Server 2000と新しいバージョンに精通している人が水中に入るのが安全かどうかを知ることができるので改善されたのでしょうが、私がこれを確認してテストで自分でチェックアウトするまでは、実稼働システムに配置しないでください。

詳細については、この質問をご覧ください。 ベースタイプを変更する方法SQL Server 2005のUDTの概要

Answer 2

コードベースのUDTは使用しません 。余分な複雑さが利点を保証するとは思わないからです。私はT-SQL UDTを使用しています 。余分な複雑さはほとんどないので、利点は努力する価値があります。 （元の投稿が不完全だったことを指摘してくれたMarc_sに感謝します！）

コードベースのUDTについて

このように考えてください。プロジェクトにマネージコードコンポーネント（アプリ）とデータベースコンポーネント（SQL Server）がある場合、データベースでマネージコードを定義することで得られる本当の利点は何ですか？私の経験では？なし。

展開はより困難です。DB展開にアセンブリを追加し、これらのアセンブリを変更し、SQL Server内でファイルなどを追加する必要があるためです。また、SQL ServerでCLRを有効にする必要があります（大したことではありませんが、パフォーマンス/メモリペナルティがないことを誰も証明していません）。最終的には、アプリケーションのコードにこれを単純に設計した場合とまったく同じものが得られます。パフォーマンスが多少向上する可能性がありますが、特にCLRのオンとオフによって overall のパフォーマンスが低下するかどうかがわからないため、時期尚早な最適化のケースとして本当に印象的です。

注：SQL ServerのCLRを使用して型を定義すると想定しています。 HLGEMはSQL Server 2000について語っていますが、私は2000に詳しくないので、外部定義されたdllにはUDFのみがあり、UDTは含まれていないと思っていました（ただし、引用しないでください...私は本当によく知りません！）

T-SQL UDTについて

T_SQL UDTは、SQLのみで定義できます（SQL Server Management Studioの<！> quot;プログラマビリティ|型|ユーザー定義データ型<！> quot;に移動します）。標準のUDTについては、実際にマスターすることを お勧めします。それらは非常に簡単であり、DDLをより自己文書化し、整合性制約を実施できます。たとえば、<！> quot; GenderType <！> quot;を定義します。 （char（1）、null不可、<！> quot; M <！> quot;または<！> quot; F <！> quot;を保持）。性別フィールドで適切なデータのみが許可されるようにします。

UDTは全体として非常に簡単ですが、この記事は、 UDTで許可されるデータを制約するルールを定義して、次のレベルに進める方法。

この質問に最初に答えたとき、複雑なコード定義型（手のひらから額へ）の概念に固定されました。だから...マークに感謝します。

Answer 3

ユーザー定義型の長所は、十分に対処されていますアレックス・パパディモウリス。短所はここに明記されています。

また、Alexの投稿で指摘されているように、sp_bindrule関数が非推奨になったことを指摘したいと思います。いつ廃止されたのかわかりませんが、今はそうなっています。実際、ルールは全体として非推奨です。

制限付きの型を作成したい場合、適切な列にチェック制約のあるユーザー定義の表型を使用することを検討します。これにより、複雑なデータ型を構築する方法も提供されます。

Answer 4

mssqlから抜け出し、別のdbmsに移行する場合に、SQL実装固有の機能を使用することを難しくすることはお勧めできません。 dwh dbsについては、mssqlから始め、oracleに移行し、昨年からhp verticaに卒業しました。