Question

我目前正在重写一个旧的会计系统，我发现了一个我怀疑很差的数据库设计。我对数据库设计没有太多经验，所以我无法确定。

在旧系统中有一个Transactions表，该表中的每一行都有一个外键到另一个表，该表由一些前缀决定。例如：

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

此表中有两列以上（实际约为15列）。如果行的凭证以L开头，则它连接到Client Invoices表。如果它以U开头，则会连接到Payments表等。

我认为这是一个糟糕的设计吗？我怎样才能改进呢？每种类型应该分成自己的列吗？是否应该有用于连接记录的凭证类型表？

Answer 1

我是否认为这是一个糟糕的设计？

是的，这是非常糟糕的数据库设计。我曾在一家公司看过类似的设计。这使得根据该表查询数据库非常困难。

每种类型应该分成自己的列吗？

这取决于表中的条目，例如，如果几乎每个id都连接到Client Invoice，Payments和其他表，那么它是好的且不太复杂的方法。根据您的样本数据，这不是正确的方法。

我是否有用于连接的凭证类型表记录通过？

这是一种更好的方法，因为它类似于通过创建表示关联的关联表来解决多对多关联。这就是我工作的公司重新设计数据库的方式。

Answer 2

有一些原则可用于设计关系数据库。在诸如L-100801之类的值的情况下，关系的逻辑问题是单个组合值编码两个通常彼此不相关的单独含义。

如果两个子值存储在单独的列中，则可以轻松地将它们组合在一起，以允许SQL设计用于处理的一次性设置处理。它们可以单独查询，单独订购等。

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