從原表中，我們可以很清晰地分出幾塊：

1、  車輛信息（型號、底盤號碼等等）。

2、  物流信息（進庫日期、銷售日期、調(diào)撥日期等等）。

3、  客戶信息（購車用戶、手機號碼等等）。

4、  銷售信息（銷售價格、終端價等等）。

5、  退貨信息（退貨原因等）。

6、  供貨商信息（供貨商名稱）。

 

我們先把較為清晰的分離出來：客戶信息、供貨商信息和車輛信息。

 

客戶信息表的基本字段設(shè)置如下：

客戶名稱、手機號碼、固定電話、地址、郵政編碼、聯(lián)系人（如果仍需要更細化，則根據(jù)實際來增加字段）。

這樣設(shè)置就夠了嗎？當然不是了。主鍵呢？有些新手可能會說，客戶名稱呀。

如果同一個客戶，由不同的聯(lián)系人來購買的時候怎么辦？聯(lián)合主鍵啊。這自然沒問題，問題是，這樣會不會太復(fù)雜了呢？其實，用一個客戶ID字段（自動編號）設(shè)置為主鍵就可以解決這個問題了。

供貨商信息設(shè)置類似，不過由于供貨商有業(yè)務(wù)來往，因此可以加上開戶行等字段，這里不再贅述。

 

車輛信息字段設(shè)置。將底盤號碼、型號、發(fā)動機型號等屬性設(shè)為字段，是毫無疑問的。這里需要詳細說明的是幾點：

1、  外鍵的設(shè)置。為了區(qū)分哪輛車是哪個供貨商提供的，供貨商ID（有重復(fù)索引）顯然是不二之選，由此建立起一對多的關(guān)系。

2、  關(guān)于冗余字段。仔細留意，你會發(fā)現(xiàn)這個表并不符合第三范式。例如，驗車員并不依賴于車輛信息而存在。再如，進庫日期、調(diào)出日期、調(diào)入日期等等幾個日期字段更不用說了。

 

先說驗車員字段。如果按第三范式，這個字段顯然應(yīng)該被剔除出去。那么，把驗車員跟車輛信息聯(lián)系起來不外乎兩個方法：

a、  建立一個驗車記錄表。

b、  以驗車員ID作為外鍵，與職員表建立一對多關(guān)系。

增加一個表，對數(shù)據(jù)庫體積的影響還是比較大的，這就要考慮其必要性了。也就是說，這個表的重要性到底有多大，才是建表的先決因素。很明顯，相較之下，b方法更佳。

但我還是棄用，而是直接使用了驗貨員姓名字段。為什么呢？

這時候，我們就應(yīng)該從業(yè)務(wù)和技術(shù)層面上來理解了。

如果使用b方法，那么很多查詢，你都不得不連上職員表�！�—你總不能讓用戶記住每個驗車員的ID吧？另外在窗體的查詢條件上，設(shè)置控件也是個問題，你不得不使用2列組合框，代碼也更加復(fù)雜。我們沒必要為了完全遵循第三范式而把問題復(fù)雜化，是吧？

 

同樣地，增加那幾個日期字段，也是出于業(yè)務(wù)的考慮的。

這幾個均屬于流水記錄信息。為這幾個字段設(shè)置采購進庫表、調(diào)撥出庫表、調(diào)撥進庫表、銷售出庫表和退貨進庫表，自是沒問題，甚至可能更加清晰。但是必須要考慮到：

a、  庫存計算。由于表較多，因此庫存計算時，必須按進庫和出庫兩類進行聯(lián)合查詢，然后再相減，從而得到實際庫存。

b、  重復(fù)計算。假定某輛車進庫后調(diào)撥到分銷，分銷賣不出去，退回總部，總部賣出去，又被退貨……那么，在設(shè)計查詢時，就得留意這個問題，以免一輛車被統(tǒng)計多次。

如果我們只關(guān)注結(jié)果，而不太關(guān)心過程的話，那么就可以增加這幾個冗余字段來代替這幾個表。實現(xiàn)思路：對車輛的每個過程更新對應(yīng)的日期字段，來表示其當前狀態(tài)。

 

事實上，這些應(yīng)該在需求分析時就要考慮的了。例如，增加“選擇”字段，可以為了方便用戶操作。再如，庫存計算。像上面那樣的設(shè)置和計算是一種方法。另一種方法就是只設(shè)置一個進庫表，只要出庫（例如調(diào)撥出庫、銷售出庫）就更新記錄。也就是說，進庫表就是實時庫存表。不過，這樣一來，當返修情況較多時，就不方便統(tǒng)計數(shù)據(jù)以便改善了。

 

表字段設(shè)計，既要考慮到業(yè)務(wù)需求，又要考慮技術(shù)可行性。其中技術(shù)層面是短板。即便有完整的開發(fā)團隊，仍不能保證所有需求都能實現(xiàn)。因此，對于不太合理的業(yè)務(wù)，應(yīng)該在管理上加以改善。軟件只能優(yōu)化流程，無法管理企業(yè)。