如果不需要，应该使用表关系

Question

我正在使用现有的客户端遗留数据库，我们将其转换为MySQL以供在线使用。

它实际上是一个巨大的表，并没有任何关系。

对于每个记录，有几个联系点 - 名字，姓氏，标题，街道，城市，州，邮政编码等，为多个实体重复。我最初的想法是将这些实体中的每一个与上面提到的列分开，并使用FK将它们与传统的连接等连接起来。

但是，在浏览完整个数据集并与原作者交谈之后，事实证明这些联系点都不会重复（每个联系点对每条记录都是唯一的），也没有任何其他与这些联系点相关的信息

所以--A​​FAICT - 除了可能的语义或透明度之外，关系表没有真正的“使用”。数据集不是很大但是它也不小（介于50,000到100,000个记录之间），所以我想知道如果保持单表结构完整并完全跳过连接可能更有效率。

有没有理由在这种情况下使用单独的表？

tyia

Answer 1

大型机几十年来一直使用平面文件格式非常有效，所以我认为你可以放弃离开桌面。话虽如此，我会考虑以下问题：

• 是否有许多查询使用'*'运算符检索数据库中的所有列，或者查询是否足够成熟，不包括那些不需要的列。如果是前者，您可能需要出于性能原因将它们移到单独的表中
• 将来是否会要求记录的多个“联系”条目。您现在可以通过现在进行转换来节省一些麻烦，而不是稍后进行转换

我怀疑它只是一个大的平面文件，可能会合适，没有真正需要规范化。如果您最终与另一个表保持1对1的关系，并且您没有在每个查询中提取所有列，则flatfile将获胜。

Answer 2

当然，即使只是为了防止技术债务。

庞大的表格维护起来总是更昂贵 - 它们具有更高的学习曲线（因此培训新开发人员的成本更高）并且它们并不像“即时”那样容易阅读（这意味着它甚至看起来成本更高）在桌子上）。

使代码尽可能立即显现应该是一个目标。包含联系信息的“USER_DATA”表格尽可能直观。这种模式无处不在，每个人都看到了它。它需要并且几乎没有想到它，因为它是如此明显。

您在上面描述的模式让经验丰富的开发人员停下来，并想知道为什么这样做。那个开发人员可能会寻找原作者，这样他就能理解为什么这样做而不是更直观的方式...

Answer 3

在这种情况下，它可能没什么用处，但是不建议在我们有大量记录的单个表中保留这么多列。最好将表拆分并将基本列存储在一个表中，如名称，密码等，以及另一个表中的其他描述性信息。

Answer 4

分割名字，姓氏，职位，街道，城市，州，邮政编码没有任何好处。 这样做的唯一好理由是为每个字段增加价值，例如你可以用'state'来定义'city'，因为它们有关系，但是你需要一个ID列来消除'Springfield的歧义，生病'形式'斯普林菲尔德，马萨诸塞'和查询将变得更加复杂，性能将略微恶化。因此，在这种情况下，将它们全部放在一个表格中以“非规范化”的形式对我来说似乎很有道理。