2014-10-18 68 views
1

我目前正在重寫一箇舊的會計系統,並且我發現了一個數據庫設計,我懷疑這個數據庫設計很差。我對數據庫設計沒有太多的經驗,所以我不能確定。改進前綴指定關係的數據庫設計

在舊的系統中有一個Transactions表,並且該表中的每一行都有一個外鍵給另一個由某個前綴確定的表。例如:

| ID | VOUCHER | 
| 1 | L-100801 | 
| 2 | U-120407 | 
| 3 | Z-622909 | 

該表中有兩列以上(實際上約15個)。如果一行代金券以L開頭,則它連接到Client Invoices表。如果它以U開頭,它連接到Payments表等。

我是否認爲這是一個糟糕的設計?我該如何改進?每種類型應該分成哪一列?是否應該有用於連接記錄的憑證類型表?

+0

你應該在[程序員堆棧交換](http://programmers.stackexchange.com/)上提出這個問題。 – 2014-10-18 19:11:10

回答

3

我是否認爲這是一個糟糕的設計?

是的,這是非常差的數據庫設計。我曾經工作過的一家公司曾看過類似的設計。這使得基於此表查詢數據庫變得非常困難。

是否應該將每種類型分爲自己的列?

這取決於表中的條目,就像如果幾乎每個ID連接到Client InvoicePayments和其他表那麼好,不太複雜的方法。根據您的示例數據,這是不正確的做法。

是否應該有一個表用於憑證類型,我用它來連接 記錄通過?

這是一種更好的方法,因爲它類似於通過創建關聯表來處理多對多關聯來表示關聯。這是我工作的公司重新設計數據庫的方式。

+0

有道理。謝謝! – 2014-10-18 19:33:36

+0

歡迎您:) – Ram 2014-10-18 19:34:03

1

有一些原則可以用來設計關係數據庫。在諸如L-100801之類的值的情況下,關係的邏輯問題在於單個組合值對兩個通常彼此不相關的單獨含義進行編碼。

如果這兩個子值存儲在不同的列中,可以很容易地將它們組合在一起,以允許SQL設計用於處理的一次一個設定的處理。他們可以單獨查詢,單獨訂購等。

如果需要,甚至可以單獨授予權限,以允許適當的用戶僅使用與他們的工作職責相關的數據。