最佳实践：数据库引用表

在数据库设计中，对于小块数据，元组vs引用表有什么感受？最佳实践：数据库引用表

例如，假设您正在设计涉及办公室管理的模式。你想记录每个员工属于哪个部门，但是对任何有关部门的信息不感兴趣。因此，你的EMPLOYEE表中有部门作为字符串/ char/varchar/etc，还是将它作为外键，与DEPARTMENT表相关联。

如果DEPARTMENT表只记录部门名称以外的任何内容，通常需要将其与EMPLOYEE表结合使用。但是，如果这包含在EMPLOYEE表中，则不能保证某些用户将呼叫人力资源“人力资源”，有些人可能将其称为“人力资源”，有些人可能称之为“人力资源”等。将其作为外键保证它只能是一件事。另外，如果有关于部门的其他信息被添加，如果它在自己的表格中，这将是容易的。

那么人们怎么想呢？当然，更多的表格和引用也可能会对性能产生负面影响。我的问题具体是在考虑Oracle 11g的情况下提出的，但我怀疑涉及的rdms类型对此设计考虑有多大影响。

来源

2013-05-02 Stumbler

我认为你回答了你自己的问题：“如果这包含在EMPLOYEE表中，你不能保证有些用户会打电话给HR'HumanResourses'，有人可能会把它称为'H-R'，有人可能称之为”人力资源“等等”......你有没有意识到你现在实际上需要担心在这一点上的表现？ – 2013-05-02 13:57:09

如果您使用相关表格，那么因为人事部门成为人力资源部门，所以您没有更新1,000,000条记录的性能问题。

您有另一种选择。创建表并将其用作数据输入的查找。但是将信息存储在主表中。

但是，我更喜欢为部门使用相关表并将部门和员工的ID存储在具有ID和开始和结束的连接表中。随着时间的推移，员工倾向于从一个部门转到另一个部门报告能够分辨出他们在什么时候是有帮助的。您需要考虑如何在设计这类事物时使用数据和报告。短视的设计很难在以后修复。

您担心有太多表格是没有根据的。数据库被设计为拥有许多表并使用连接。如果您的索引正确，那么对大多数数据库不会有性能影响。而且你知道什么，我知道很多很多表有很多数据表的数据库，这些数据表现得很好。

来源

2013-05-02 14:05:08 HLGEM

FWIW，我有一天在我的台式电脑上测试了级联更新。它在不到3秒的时间内将更新级联到5000万行的300万行中。（PostgreSQL 9.1。电脑没什么特别快或特别的。）我不认为我多年来一直担心级联更新的速度。所以我同意“更多表格”，但不要总是同意“使用ID号码”。 +1 – 2013-05-02 14:25:20

如果你正在处理真正的海量数据集，那么你只需要担心这类事情对性能的影响。对于任何这样的常规办公环境系统，更喜欢标准化的模式。

来源

2013-05-02 13:59:19 Rik

最佳实践：数据库引用表

回答

相关问题