SQL Server 使用者定義型別

在同事報案筆錄看到新鮮玩意兒,資料表的某個欄位型別不是 VARCHAR 不是 DATETIME 不是 INT,而是某個沒看過的名稱(如下圖示意),研究了一下,是所謂的使用者定義型別(User Defined Type, UDT),過去只在教材看過,首次觀察到活體。

使用 UDT 有什麼好處?

UDT 可指定型別、資料長度及精確度、是否允許 NULL,還能定義預設值跟規則,定義一次可重複用於多個資料表、Stored Procedure,實現重用性並維持一致性,良好的 UDT 命名能望文生義,具自我說明(Self-Documentation)效果。另外,UDT 整合 SQLCLR 還能用 C# 實現複雜的邏輯,威力強大。(註:整合 SQLCLR 需留意非原生邏輯執行效能問題[案例])

延伸閱讀:

原本以為 UDT 最大的優點應是 -- 當欄位需要放寬,只需修改 UDT,所有使用它的資料表可一次放寬,雖然直覺技術難度甚高,如能做到價值連城。爬文之後發現是我想多了 - UDT 只能 CREATE 跟 DROP,不能 ALTER,如要更改,必須先另建一個 UDT,將逐一修資料表改用型別。參考 1 2

雖然不如想像中強大,我還是想試試 UDT 的威力,打算建個 UDT 玩玩:

很快地,我又被潑了一盆冷水 - 無法使用 SSMS 管理介面新增 Defaults 跟 Rules(下圖黃色標示處),只能透過 T-SQL 指令建立。
查了文件,SQL Server 未來將不再支援 CREATE DEFAULTCREATE RULE,已不建議使用,應該是 SSMS 不提供操作介面的原因。


由此看來,UDT 僅存型別與長度統一及自我說明的優勢,好處有限,個人對它沒有愛,不推。

歡迎推文分享:
Published 14 May 2018 11:24 PM 由 Jeffrey
Filed under:
Views: 1,388



意見

沒有意見

你的看法呢?

(必要的) 
(必要的) 
(選擇性的)
(必要的) 
(提醒: 因快取機制,您的留言幾分鐘後才會顯示在網站,請耐心稍候)

5 + 3 =

搜尋

Go

<May 2018>
SunMonTueWedThuFriSat
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789
 
RSS
創用 CC 授權條款
【廣告】
twMVC

Tags 分類檢視
關於作者

一個醉心技術又酷愛分享的Coding魔人,十年的IT職場生涯,寫過系統、管過專案, 也帶過團隊,最後還是無怨無悔地選擇了技術鑽研這條路,近年來則以做一個"有為的中年人"自許。

文章典藏
其他功能

這個部落格


Syndication