2010-09-09 134 views
0

我爲系統
設計如下表格,它看起來像包裹傳送系統。數據庫表格設計

例如,用戶接收到的包後,郵遞員應在系統記錄,
和狀態(歷史表)「交付」,並且操作者是這郵遞員,
當前狀態(狀態表)是當然,「交付」

history table: 
+---------------+--------------------------+ 
| Field  |  Desc    | 
+---------------+--------------------------+ 
| id   | PRIMARY KEY   | 
+---------------+--------------------------+ 
| package_id | package_tacking_id | 
+---------------+--------------------------+ 
| state  |  package_state  | 
+---------------+--------------------------+  
| operators | operators    | 
+---------------+--------------------------+ 
| create_time| create_time   | 
+---------------+--------------------------+ 

state table: 
+---------------+--------------------------+ 
| Field  |  Desc    | 
+---------------+--------------------------+ 
| id   | PRIMARY KEY   | 
+---------------+--------------------------+ 
| package_id | package_tacking_id | 
+---------------+--------------------------+ 
| state  | latest_package_state | 
+---------------+--------------------------+ 

以上只是基本信息記錄,其他的一些信息(
像發票,目的地,...)應記錄爲好。
但也有不同的服務類型,如S1和S2,S1爲它不需要
記錄發票,但S1的需要,也許S1需要一些其他信息記錄
(如最終用戶的電話)。

畢竟,在發送方式站有附加信息要記錄,
和不同的服務類型信息類型是不同的。

我的問題:

  1. 針對不同的業務類型,應我需要聲明不同的表(選項A)或只是
    一個大表,可以記錄所有類型(選項B)的所有信息?
  2. 如果選項A,因爲上面的基本信息是必須的,
    如何防止在不同的表中存在重複的字段?

回答

0

我對您的問題沒有完成的答案,但您可以嘗試在表設計遺傳模式

Service Table(service) : used to put common or not-null columns in all kinds of services. 
sv_id - internal key(PK) 
sv_data_1, sv_data_2, ... 
Service 1 Table : dedicated attributes to service 1 and 'inherited from service'. 
sv1_id - internal key(PK) and foreign key to service(sv_id) 
sv1_data_1, sv1_data_2, ... 

等等到其他專用服務表...

  1. 爲了方便起見(和性能),增加一個「sv_type」列來表示確切「子類型表」如果您需要列出各種服務,請使用servcie。
  2. 否則,只需使用'內部連接'即可獲得特定類型的服務。

儘管我們需要使用'join'來獲取特定類型服務的所有屬性,但是架構顯示會爲您的問題構建'null-free'解決方案。

如果您關心性能問題,有一件好事:使用兩個主鍵完成特定類型服務的連接表。

關於性能的更多信息,當您需要更快速的查詢並且不用擔心服務的空錯誤和類型錯誤問題時,您可以使用連接的基表創建緩存表。