不定字段數目的數據庫表設計和數據結構

可能采用四種技術：

動態增加數據庫表字段

預留足夠的空白字段，運行時作動態影射

用xml格式保存在單字段里

改列為行，用另外一個表存放定制字段

現在我們來分析一下四種技術的優劣，不過首先可以排除的是第一點動態增加字段的方法，因為在實際操作時候幾乎是不可能的(sqlserver太慢，oracle索性不支持)，基本可以不討論就排除。剩下后三點。

先來討論預留空白字段的方法，基本原理就是在數據庫表設計的時候加入一些多余的字段，看下面的代碼：

CREATETABLESample(??name?varchar(12),????field0?varchar(1),??field1?varchar(1),????fieldN?varchar(1)}

然后看實際運行時候的需要，動態分配字段給系統使用，也許需要一個這樣的結構來描述分配情況：

publicclassAvailable{??public?int?CurrentUnusedFieldNumber;??public?Hashtable?FieldToRealName;}

也許某一時刻的數據狀況是這樣的： CurrentUnusedFieldNumber=3, 哈西表FieldToRealName包含內容是("field0"="SomeId", "field1"="AnyName", "field2=IsOk")

現在的問題是如果要配合Hibernate，如何來處理？以上段的數據使用狀況為例子，如果我們的類定義是這樣：

publicclassEntity01{??public?string?Name;??public?string?SomeId;??public?string?AnyName;??public?bool?IsOk;}

也許只需要修改一下xxx.hbm.xml，把 SomeId 和 field0 做成對應就ok了。但是在運行時我們怎么知道會有這樣的類定義？除非我們做動態代碼生成，自動編譯也許可以，但是問題也許就到其他方面去了；如果我們不用動態定義，那么類就只能是這樣：

publicclassEntity01{??public?string?Name;??public?Hashtable?ExtraFieldAndValues;}

使用的時候，用 entity01.ExtraFieldAndValues.setValue("AnyName", "boss") 的方式來引用，也許這樣是修改最少的了，但是問題是Hibernate不支持這樣的方法。

再來討論單字段存儲的方法，我們使用這樣的數據庫表定義

CREATETABLESample(??Name?varchar(12),??Xml?CLOB(102400)?//僅作說明而已)

然后對應這樣的類定義

publicclassEntity01{??public?string?Name;??public?string?Xml;??public?Hashtable?ExtraNameAndValueFromXml;}

我們的代碼就可以這樣使用：string id = entity01.ExtraNameAndValueFromXml.getValue("SomeId") 了。這樣解決看起來很不錯，不僅不需要Available表，而且看起來Hibernate對它的支持也很完美，但是致命的問題在于：如果保持高效的查詢？除非數據庫系統本身對此有支持，否則就只能用低效的substring或者like做查詢，這在大批量數據中根本就不可行。

是不是折衷一下，把兩種方法的優點和起來？問題有來了：怎么保持兩者之間數據的同步？難道要我們用存儲過程去解析xml內容？

所以，一個兩難的問題，需要我們認真去解決。我們通過認真的需求分析，也許可以減少可變字段的數量，但是只要有一個可變字段或者可變的可能性存在，我們始終要去解決這個兩難的問題。

期待繼續討論。
(新增部分)
還有一種方法就是改列為行，用另外一個表存放擴展字段，定義可以如下：

CREATETABLESampleFields(??idSample?Integer,??fieldName?varchar(30),??fieldValue?varchar(100))

其中idSample關聯到Sample表的id字段(我沒有寫出來)。這樣的話，Hibernate很容易支持，也可以支持Sql的查詢，而且可以支持把內容放到Hashtable中去，看起來是目前最好的方式了。但是在大容量數據的時候，SampleFields表的數據會是主表數據量的N倍(看定制的字段數目多少而定)，同樣存在有很嚴重的性能問題。
哪位高人還能再給一個方案？
---------2005-7-22新增-----------
很多朋友給出了很好的建議，其中蛙蛙池塘 給出了一個表結構，因為看起來不甚方便，我把類圖畫出來如下：
圖所表示的內容簡單來說是這樣：
1。一個很寬的表ProductAttributeValues，包含用到的幾乎所有可能的類型的值，但是每次只能用一個類型的值
2。將可變的列轉為行，存放到上表中
3。為了存放類型定義和一些下拉列表的內容，設計了ProductAttributeTemplates和關聯的其他表
4。ProductListItems中存放Product中所有項的說明和順序。
這種思路其實就是把產品的“知識級”(設計模式用語)和“操作級”都表現出來了，如果要劃分，則圖的左上角三個表屬于“操作級”，其余的屬于“知識級”。wljcan 網友建議我去看《設計模式》的“觀察模式”，我發現上圖其實就是一種和“觀察模式”相似的設計。《設計模式》看了很久都沒能看下去，不過這幾天正在看“觀察模式”，等有心得了，再來看看能不能對上圖的結構修改一下。怡紅公子 提醒說oracle和sql server對xml字段其實已經不錯了，所以找了一下，但是真的是既產品中恐怕還是不敢用，不知道性能如何。雖然采用xml方式是我最推崇的方法。而且一旦采用xml方式存儲，恐怕就會有changyu 網友提醒的數據類型問題，要存一個圖片的話恐怕就歇菜了(當然也不是說xml中就一定不能存圖片)。
不過我現在覺得xml字段還是要的，作為輔助存儲手段，因為畢竟未來查詢起來可能會更方便些，然后結合“觀察模式”也就是類似上圖的方法作為主要的存儲手段，雖然有一些冗余，結合我的使用 NVelocity 解析 PowerDesigner 的cdm文件 ，工作量也不會太大。
再研究研究看看。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的不定字段数目的数据库表设计和数据结构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。