推薦：SQL Server 2005中插入XML數(shù)據(jù)方法
SQL Server 2005數(shù)據(jù)庫中增加了XML類型，在創(chuàng)建表的時候可以指定某一列為XML類型，示例如下： CREATE TABLE customers ( name VARCHAR(20) NOT NULL P

信息系統(tǒng)交付使用之初，數(shù)據(jù)庫表結(jié)構(gòu)的設計往往邏輯結(jié)構(gòu)清晰，管理使用方便，但是當信息系統(tǒng)項目運行一段時間，隨著業(yè)務的不斷變化和增加，處理流程不斷的變革，信息系統(tǒng)需要從前臺界面到后臺數(shù)據(jù)庫的完善和修改，勢必要對數(shù)據(jù)庫表結(jié)構(gòu)必須要進行擴展。我們通常的數(shù)據(jù)庫擴展往往采用增加備用字段、擴展字段的內(nèi)涵、增加主從表和管理表的方式，這種數(shù)據(jù)庫表結(jié)構(gòu)的擴展往往會帶來營運的中斷和操作的風險，本文通過分析常見的數(shù)據(jù)庫庫表結(jié)構(gòu)的擴展方法中的不足，提出了幾種基于 pureXML 方式的數(shù)據(jù)庫表結(jié)構(gòu)的擴展模式，可以成功的結(jié)束數(shù)據(jù)庫擴展的技術(shù)難題。

概述

信息系統(tǒng)的建設往往遵循業(yè)務調(diào)研、需求分析、再進入到數(shù)據(jù)庫和軟件的概要設計、詳細設計、代碼編寫等等階段，在這個過程中數(shù)據(jù)庫設計者往往根據(jù)已有的業(yè)務調(diào)研、需求分析的成果進行數(shù)據(jù)庫表結(jié)構(gòu)的設計，這時的數(shù)據(jù)庫的設計者是通盤考慮，全局謀劃所設計的數(shù)據(jù)庫結(jié)構(gòu)，整個庫表結(jié)構(gòu)邏輯清晰，管理方便并且符合 3NF 的要求。信息系統(tǒng)項目運行一段時間，隨著業(yè)務的不斷變化和增加，處理流程不斷的變革，這種業(yè)務需求的驅(qū)動下，我們的軟件體系也需要不斷的修改和完善，這種修改和完善不僅是界面的調(diào)整和模塊的增加，而且必須對數(shù)據(jù)庫表結(jié)構(gòu)進行必要的調(diào)整和修改。

這種項目維護期間的數(shù)據(jù)庫調(diào)整和擴展，必須對數(shù)據(jù)庫設計文檔進行修改，對數(shù)據(jù)字典進行調(diào)整，理想的情況是文檔齊備、資料完整，但實際工作中，由于設計和開發(fā)人員的責任心和對文檔的輕視，每次對數(shù)據(jù)庫表結(jié)構(gòu)的調(diào)整都會造成數(shù)據(jù)庫庫表結(jié)構(gòu)混亂，為今后的工作帶來系統(tǒng)管理、維護和軟件的再次修改和調(diào)整帶來隱患;其次，數(shù)據(jù)庫的擴展和調(diào)整中，對數(shù)據(jù)庫設計者要求很高，很容易導致數(shù)據(jù)庫設計中范式設計的隱患，進而造成數(shù)據(jù)庫性能的急劇下降;最值得注意的是，由于數(shù)據(jù)庫存儲有大量的業(yè)務數(shù)據(jù)庫，每次對數(shù)據(jù)庫字段的修改和調(diào)整必須停機操作，從而帶來運營的中斷和操作的風險。特別是對于上線運行的核心業(yè)務系統(tǒng)，和若干 7×24 小時的業(yè)務系統(tǒng)，每次的數(shù)據(jù)庫停機操作對營運的影響非常的巨大，而且還可能引來不良的社會影響。

為了對數(shù)據(jù)庫進行有效的擴展，實際工作中往往采用預留備用字段、字段內(nèi)涵擴展、增加從表擴展和增加關聯(lián)表的方式進行擴展，這種擴展往往存在若干的問題：

設計之初預留備用字段帶來的不足

為了減少對今后對數(shù)據(jù)庫表中的字段調(diào)整，某些設計者在設計之初，根據(jù)經(jīng)驗對若干可能擴展的表中預留部分備用字段。預留備用字段的方式在某些程度上可以增加擴展的靈活性，但是確存在如下隱患：

預留字段的數(shù)量無法預測 , 預留 N 個還是預留 N 1，由于無法預知需要預留的數(shù)量造成擴展的不確定性;

預留字段的類型無法預測，預留字符型還是數(shù)值，無法去預測和評估;

常見在預留的擴展字段中，這些預留的擴展字段往往會破壞數(shù)據(jù)庫最基本的范式要求，數(shù)據(jù)庫的范式的最基本要求就是原子性和唯一性，而擴展的字段本身的定義是不明確的，這是不未確定的，也就是非原子的和非唯一的。

表結(jié)構(gòu)的字段數(shù)據(jù)量不擴展，擴展若干字段的內(nèi)涵

數(shù)據(jù)庫的調(diào)整會帶來運營的風險，部分數(shù)據(jù)庫設計者為了應付數(shù)據(jù)庫存儲的需要，不對數(shù)據(jù)庫表結(jié)構(gòu)的字段的數(shù)量進行增加，而是非常“聰明”的將某個字段的內(nèi)涵進行擴展，使得某些字段中同時存入 2 以上含義，由程序分析存入該字段的值的屬性和內(nèi)容。例如：某字段原定義為 VARCHAR(4)，如果存儲字母開頭的值，如 A001 表示意思 XX;存儲數(shù)值開頭的值，如 1000 表示意思 YY;還有一種方式就是采用間隔符，對字段進行擴展，例如 A001 1000 等形式。我們的數(shù)據(jù)庫設計中，數(shù)據(jù)庫表中的每一個字段都是單一屬性，是不可再分的、原子性的，這個是數(shù)據(jù)庫設計的第一范式理論，任何的數(shù)據(jù)庫設計都應該遵守第一范式。這種設計不僅違反的數(shù)據(jù)庫設計的第一范式理論，而且造成讀取數(shù)據(jù)時需要程序進行“解碼”后才能進行查詢、統(tǒng)計等等，使得數(shù)據(jù)庫的整體性能大大降低。

增加從表，但又不能確定從表的數(shù)量

當對庫表進行擴展時，往往遇到存在 1:N 的情況時，這時必須增加從表來應對數(shù)據(jù)庫的擴展，但是由于每次增加數(shù)據(jù)庫從表時，無法預測需要增加多少個從表，每次增加從表都會造成數(shù)據(jù)庫的修改和調(diào)整。

增加關聯(lián)，但關聯(lián)表的字段無法預測

由于業(yè)務邏輯的改變，如果發(fā)現(xiàn)原表 T1,T2 存在 N:M 的關系時，必須增加關聯(lián)表，但是關聯(lián)表的字段數(shù)量又無法預測 , 每次對關聯(lián)表的調(diào)整又會造成對數(shù)據(jù)庫的影響。

通過對數(shù)據(jù)庫表結(jié)構(gòu)中經(jīng)常采用表和字段擴展的方式進行分析，我們都會發(fā)現(xiàn)對數(shù)據(jù)庫的修改，往往會造成諸多的不便，而且值得注意的是每次修改數(shù)據(jù)庫往往是業(yè)務需要非常緊迫，考慮到之前確保之前程序的穩(wěn)定性和可靠性，此時又不能對原有的數(shù)據(jù)庫進行調(diào)整和重組，DBA 往往只能進行部分數(shù)據(jù)庫表結(jié)構(gòu)的字段，往往最終導致數(shù)據(jù)庫表結(jié)構(gòu)混亂，以及管理維護的失控。

分享：ASP.NET2.0向其它網(wǎng)頁傳遞信息的方法
傳統(tǒng)辦法 為了便于比較，我想花一分鐘來回顧網(wǎng)頁傳遞數(shù)據(jù)的老方法。HTML的表格元素有一個action(動作)屬性，用來指定服務器端哪項資源(所謂資源，是指一個網(wǎng)頁、一段腳本、程序等)來處理這些