之前提到了約束的一些特點，看起來也沒什麽大不了的問題，http://www.cnblogs.com/wy123/p/7350265.html
以下以實際生產運維中遇到的一個問題來說明規範的重要性。

如下是一個簡單的建表腳本，表面上看起來並沒有什麽問題。
其中創建了3個約束，一個主鍵約束，一個唯一約束，一個默認值約束，該腳本執行起來沒有任何問題。

USE Test
GO

if exists(select 1 from sys.tables where name = ‘TestConstraint‘)
    drop table
 
 dbo.TestConstraint
GO

create table dbo.TestConstraint
(
    id int primary key,
    name varchar(100) unique,
    createdate date default getdate()
)
GO

如下是上述建表腳本執行之後生成的約束信息，可以看到生成的約束都是按照一定規則+隨機字符生成的約束名字。
實話說這不是我們想要的命名方式，之前提到過，我們不願意看到數據庫中存在非預期或者說是隨機的命名信息.
當然不僅僅是強迫癥的原因，非要看到一個規範的命名。

隨著需求的變更，需要修改一個字段的類型，當執行修改字段類型的腳本的時候，發現報錯了，原因是字段上有一個約束，如果想要修改字段類型，就要先刪除這個約束。

既然無法直接修改字段類型，那麽就刪除該約束，再重定義字段類型，也是沒有問題的。

　　但是問題就出在這裏，變更腳本的執行肯定是從開發環境開始修改，然後測試，然後再上測試環境，測試通過，最後才上生產環境執行。
　　這裏沒辦法保證，在開發環境寫完的腳本，可以直接在測試環境執行，可以在生產環境執行。
　　整個流程基本上是自動化執行的，腳本也是通用性執行的，如果中間改來改去，是不是要浪費很多無所謂的時間。
　　難不成開發環境寫一個，測試環境寫一個，生產環境寫一個？並且需要一個一個用SSMS打開或者通過系統表來查看具體環境中字段上約束的名稱？
　　某些情況下，對於某些敏感的生產數據庫，不是輕易就可以訪問的。
　　當然有人說老子可以隨時連上生產庫，隨時可以通過SSMS圖形界面進行操作，這種情況例外不討論。
　 此種情況顯然是不太符合規範的，並且是增加了無所謂的工作量，我想有價值的工作絕不是做這些毫無意義的重復性勞動吧。

要想規避此類情況，就要從建表開始，建表的過程中就執行規範的名字，然後這個建表腳本不管在哪個環境，生成的約束都是指定的名字。
在上述修改字段類型的情況下，寫的腳本就可以通用在各個環境中了。

USE Test
GO

if exists(select 1 from sys.tables where name = ‘TestConstraint‘)
    drop table dbo.TestConstraint
GO
--不要在建表的時候指定約束，這樣會生成隨機的約束名字
create table dbo.TestConstraint
(
    id int not null,
    name varchar(100) ,
    createdate date 
)
GO

--主鍵約束
alter table dbo.TestConstraint
    add constraint [PK_TestConstraint] primary key  clustered (id)  
GO

--唯一約束
alter table dbo.TestConstraint
    add constraint [UQ_TestConstraint_name] unique(name)  
GO

--默認值約束
alter table dbo.TestConstraint
add constraint [DF_TestConstraint_createdate] DEFAULT GETDATE() FOR createdate
GO

當然在修改字段類型的腳本為了嚴謹期間，也要做到可以重復執行，以下僅為示例，總之就是要盡可能規範性和嚴謹性，以減少無所謂的麻煩。

if exists(select 1 from sys.default_constraints where name = ‘DF_TestConstraint_createdate‘)
begin
    alter table dbo.TestConstraint
    drop constraint DF_TestConstraint_createdate
end
go

alter table TestConstraint
alter column createdate datetime
GO

alter table dbo.TestConstraint
add constraint DF_TestConstraint_createdate DEFAULT GETDATE() FOR createdate
GO

數據庫從安裝，到對外開發使用，到後期的運維，甚至到退役，有一系列的規範性操作。
本文僅從建表時候約束這個個非常小的方面，來說明規範性對開發以及運維工作的影響。
一屋不掃可以掃天下，規範無小事，數據庫也不例外，
說到規範，很多人不屑，認為可有可無，比如說破嘴皮子的三範式，
有人拿著“適度冗余”來逃避三範式，覺得“適度冗余”是一個時髦+時尚+牛逼+鄙視呆板的一種設計，
對於關系數據庫，違反三範式的“適度冗余”一旦考慮的不夠周全，遇到數據的不一致性，就算你死了，你自己去修復數據吧。

以上“改字段”一句話看起來簡單，遇到這種事，背後一系列操蛋性的操作，如果經常有類似的問題，工作的價值又在哪裏呢？
從最基本的規範就可以看出來一個團隊的工作風格和技術能力。

從一個簡單的約束看規範性的SQL腳本對數據庫運維的影響