为简单而去规范化：不好的主意？

Question

阅读question 后，我了解到非规范化不是简单的解决方案。这个案子呢？

我有新闻文章，其中包含网站文章将发布到的列表。后者可以通过表和多对多关系（我认为通过交叉表）以标准化方式表示。但简单的解决方案是为站点文章将被发布到（publish_to_site_1、publish_to_site_2 等）添加一堆布尔值。假设网站是：

1. 数量少
2. 不会随时间改变
3. 除了名称之外没有任何字段

这仍然是一个糟糕的主意吗？多对多的关系似乎有些麻烦，但我以前在这种情况下做过（而且看起来很麻烦）。

注意：我在 Rails 中执行此操作，并没有那么痛苦。另一方面，元编程让这样的事情变得微不足道

(1..5).each { |site| do_something(article["publish_to_site_#{site}".to_symbol]) }

Answer 1

如果确实满足了这些条件，那么不，这不是一个糟糕的主意。

事实上，这甚至不是非规范化：非规范化通常意味着您为了性能而冗余地存储了一些信息。在您的示例中，由于站点本身没有字段，因此您不会冗余存储内容。您只是剥夺了自己在未来为网站存储额外字段的机会（不违反规范化或重新设计数据库）。

所以，这没关系（标准化）：

article                        show_on_stackoverflow    show_on_my_blog
-----------------------------------------------------------------------
Denormalize for Simplicity             YES                     NO
More simplicity                        YES                     YES
...

但这不行（冗余）：

article                        show_on_stackoverflow    stackoverflow_mainpage_url   show_on_my_blog    my_blog_mainpage_url
------------------------------------------------------------------------------------------------------------------------------
Denormalize for Simplicity             YES              http://stackoverflow.com            NO          http://my.blog.url       
More simplicity                        YES              http://stackoverflow.com            YES         http://my.blog.url
...

Answer 2

如果您将布尔值“sites-article-will-be-published-to”仅视为主要数据的属性，例如“isGreen”、“hasHair”、“isBipedal”，那么单个表在有一个表Green{<true>, <false>}的外键是不正当的感觉。

显然，如果你的 3 个条件不继续成立，那么下一个人将有不平凡的工作要做，但“尽可能简单，但不要更简单”有其效用。

Answer 3

就个人而言，我认为我不会非规范化。我认为，如果您熟悉 SQL，则加入单个 n:n 关系并不是那么麻烦。可能很麻烦的是对不同的查询使用非规范化结构。例如，您确定永远不需要文章发布到的所有网站的列表...？

我不会说你的方法很糟糕，但我通常更喜欢规范化的数据，很高兴地做另一个连接:)

干杯 马蒂亚斯

Answer 4

假设二是不现实的。

因此，完全按照“如果这些条件确实满足，那么不​​，这不是一个可怕的想法。” : 是的，这是个糟糕的主意。