原文地址：http://blog.csdn.net/liu7537/article/details/713966

（三）單表模式 單表模式，就是把相關子類的屬性統統集中在一個表裡，通過“類別”欄位來區分表內記錄所屬的子類以及該類的有效屬性。在實際案例當中，單表模式的應用還是很廣泛的。舉個例子，有車的朋友現在拿出你們的《中華人民共和國機動車行駛證》，翻到“副頁”，看看副頁登記的檔案指標。下圖為推測設計圖、不代表真實設計。

我是2006年2月份買的車，我的機動車行駛證副頁記載瞭如下檔案指標：“號牌號碼、車輛型別、總質量、整備質量、核定載質量、準牽引總質量、核定載客、駕駛室共乘、貨箱內部尺寸、後軸鋼板彈簧片數、外廓尺寸、檢驗記錄。”瀏覽本文的朋友可以跟自己的行駛證對照一下，尤其是老司機，看看若干年前發的行駛證和現在的有沒有區別。 在這裡大家可以很清楚的看到，上述指標中“號牌號碼、車輛型別、總質量、整備質量、外廓尺寸、檢驗記錄”是各種型別的車輛的公共屬性，“核定載質量、準牽引總質量、駕駛室共乘、貨箱內部尺寸、後軸鋼板彈簧片數”是貨運車輛的專有屬性，“核定載客”是客運車輛的專有屬性。 根據經驗我推測，就此種表現形式而言，公安機關交通管理部門的計算機系統應該就是採用“單表模式”進行的設計。通過這一個表就可以容納包括貨車、客車、轎車、摩托車、農用車等所有型別的車輛檔案。這裡面有一個“車輛型別”屬性，這個屬性就是用來區分當前記錄所屬類別，程式程式碼根據這個屬性的值來確定當前檔案記錄的哪些屬性是有效、且需要記錄和列印的，哪些屬性對當前記錄來說是無效的。比如我行駛證上的車輛型別是“轎車”，除公共屬性以外，只有“核定載客”指標列印了一個“5人”字樣，其餘指標列印的都是“--”字樣，因為這些指標都是貨車才有的，對轎車而言是無意義的。 這種設計有一個明顯的好處——如果事先對車輛檔案都有哪些指標調研的很充分，且後期基本上不需要擴充套件，那麼系統執行時無論遇上什麼型別的車輛檔案都不需要變更程式，具有很強的通用性。很明顯，行駛證是套打的，這種設計便於大批量的製作證件底單。因為不管什麼型別的車輛檔案都是這個格式，只要開動機器印刷便是。 凡事有利就有弊，這種設計的弊端也很明顯。首先是給人的印象不是很人性化。我明明買的是轎車，你發給我的證件搞那麼多貨車的指標在上面幹嘛？浪費版面！其次，如果一旦後期需要對某種型別的車輛檔案擴充屬性（無論你前期的需求調研多麼充分，都不能保證以後不會變化），假設國家新頒佈一部法規或者國標，要求必須在行駛證上記載客車的“發動機排量”、其他型別的車輛不作要求，那麼按照這種設計，所有車輛（包括“無辜的”貨車在內）都要換證（呵呵，不知道這種換證收不收工本費）！ 宣告：以上例子僅僅是我的推測，用以說明“單表模式”。我沒有交通管理部門的工作經歷，如果與實際情況不符，歡迎同行批評指正。