資料表是否要繼承主要根本是因為系統分析後得出的領域模型而來,所以應該由系統分析來著手;而探討"資料表繼承"主要是因為Martin先生在他的書出提出物件導向系統與資料庫阻抗不匹配,為了讓兩者盡可能的搭配所以有了資料表繼承這一手法,而主要的手法分成三種:

1. TPH(Table per Hierarchy)
2. TPT(Table per Type)
3. TPC(Table per Concret Type)
   這三種手法各有其優缺點,故需要在適當的情境下擇一或是作適當的改變,切莫為了繼承而繼承,否則會應了前輩們常說的一句話"設計太爛,系統就會拿效能懲罰你"

你要的功能在SQL Server裡有，它在早期的SQL產品中就有了，不過它不叫繼承，叫模版工程才對。因為它跟繼承的觀念完全不同。
在SQL裡，有一個Model

你只要在裡寫好你要的所有資料表樣版，剩下的開新資料庫動作，系統會自動幫你完成相關資料表的建置工作，完成後，你再自行修改所需的欄位即可。

:::舉例來說，A , B , C 三個資料表都必須設計
:::CreateDate , CreateUser , UpdateDate , UpodateUser
:::某些欄位必須修改資料型態或長度(例如：ERP系統中的單號)
既然是大型專案
定要先建立 [資料辭典]
開 Table 的必要欄位是由 [開檔系統],
統一開立 PK/FK/Default Value/Constrain...
Table 的 Internal ID / Web UU ID / Search Key / Search Name
統一系統做好