2014-10-18 66 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设计用于处理的一次一个设定的处理。他们可以单独查询,单独订购等。

如果需要,甚至可以单独授予权限,以允许适当的用户仅使用与他们的工作职责相关的数据。