我有一个数据库，其中包含一些在某些表中重复的信息。
我想知道用这些信息创建一个表是否有趣，而在另一个表中，我只放了 id。
这很有趣，因为使用这种方法我没有冗余。但是在我的请求中我将不得不在我的表之间做很多关节，我担心我的请求会更慢。
（如果 symfony 有所改变，我会使用它）
【问题讨论】：
标签： sql symfony1 database-design
听起来有问题的“信息”是构成关键值的数据。如果是这样，听起来数据库设计者喜欢使用自然键，而您更喜欢使用代理键。
首先，这些都只是风格问题。如果自然键值是复合的（即涉及多列）并且出于数据完整性目的而包含在其他列中，则它们不是冗余的。
其次，正如您所观察到的，当谈到代理键的性能时，您必须权衡更有效的数据类型（例如单个整数列）的优势与需要编写更多 JOIN 的性能下降。请注意，使用代理往往会使约束编写起来更麻烦，例如当规则所需的值在另一个表中并且您的 SQL 产品不支持 CHECK 约束中的子查询时，您将需要使用触发器，这会降低高活动环境中的性能。
进一步考虑性能不是唯一的考虑因素，例如使用自然键值往往会使数据更具可读性，从而使架构更易于维护，因为物理模型将更紧密地反映逻辑模型（代理键根本不会出现在逻辑模型中）。
【讨论】：
你说的是Normalisation。与许多设计方面一样，这是一个权衡。
在数据库中存在重复会导致许多问题 - 例如，在更新数据时如何使这些重复保持同步。所以插入和更新可能会因为重复而变得更慢。因此，我们倾向于规范化数据库以避免这种重复。这确实会导致更复杂的查询，并可能导致一些检索开销。
如果您小心设置正确的索引，现代数据库产品往往会很好地完成此类查询。
因此，我的出发点是规范您的数据，避免重复。然后在特殊情况下，可能只对真正重要的部分进行非规范化。例如，假设您的数据库的某些部分很大，主要是查询而不是更新（例如历史订单信息），那么可能会对该位进行非规范化。
【讨论】：
这不是风格的问题。
答案是，正如搜索者已经确定的那样，删除重复；正常化。将它们全部拉到一张表中，并在使用它们的任何地方放置一个外键。
现在整数 FK 可能是“整洁的”，但任何好的、短的、固定长度的密钥都可以。可变长度键对性能非常不利，因为每次搜索索引时都需要对键进行解包。
规范化数据库的本质是更多、更小的表，这比具有更少、更大表的非规范化数据堆快得多。习惯就好。
只要您在键上加入，加入本身不会花费任何费用；十个连接构造一行的成本不超过五个。成本以表格大小计；使用的指数；分布;索引列的数据类型；等等。关系 dbms 是为规范化数据库精心设计的。
如果您需要查找查找，那么就是这样。只需确保表格已标准化。
【讨论】：
如果你不规范化
这是对其他2个答案更实用的点......
【讨论】：