在数据库设计中，对于小块数据，元组与引用表的感受是什么？
例如，假设您正在设计涉及办公室管理的模式。您希望记录每个员工所属的部门，但对与部门相关的任何信息不感兴趣。那么你的部门作为字符串/ char / varchar / etc在你的EMPLOYEE表中，或者它是一个外键，与DEPARTMENT表相关联。
如果DEPARTMENT表正在记录除部门名称以外的任何内容，则通常需要将其与EMPLOYEE表结合使用。但是，如果这包含在EMPLOYEE表中，则无法保证某些用户会将其称为HR“HumanResourses”，有些人可能将其称为“HR”，有些人可能将其称为“人力资源”，等等。将其作为外键保证它可能只有一件事。此外，如果要添加有关部门的其他信息，如果它位于自己的表格中会很容易。
那么人们怎么想呢？当然，更多的表和引用也可能对性能产生负面影响。我的问题特别是考虑到Oracle 11g，但我怀疑所涉及的rdms的类型对这个设计考虑很重要。
答案 0 :(得分：2)
如果你正在处理真正庞大的数据集，你只需要担心这种事情对性能的影响。对于像这样的任何常规办公环境系统，更喜欢规范化架构。
答案 1 :(得分：2)
如果您使用相关表格，那么您不会遇到更新1,000,000条记录的性能问题，因为人事部门已成为人力资源部门。
你有另一种选择。创建表并将其用作数据输入的查找。但是将信息存储在主表中。
但是，我更喜欢选择将相关表用于部门，并将部门和员工的ID存储在具有ID和开始和结束的连接表中。随着时间的推移，员工往往会从一个部门转到另一个部报告能够告诉他们什么时候在哪个部门是有帮助的。在设计此类事物时，您需要考虑数据在一段时间内的使用情况以及报告中的使用情况。短视设计以后很难修复。
你对太多牌桌的担忧实在是没有根据。数据库设计为具有许多表并使用连接。如果您索引正确，则不会对大多数数据库产生性能影响。你知道吗，我知道有许多表的实际数据库，这些表有数TB的数据表现得很好。