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