扁平化数据库设计什么时候可以接受

Question

现在什么时候可以使用扁平数据库表设计。曾经？我的意思是，当我们应该创建另一个表的键来存储多行时，什么时候可以放弃关系数据库设计的智慧并恢复不包含链接的平面表结构，添加额外的列来添加更多数据.

我正在与产品管理团队讨论一些想法。当我最初问“为什么所有这些桌子本质上都是平的”这个问题时，我被告知 “以读取为中心的数据库通过平面表结构显示出更好的性能。”

我对这个解释很挣扎，因为扁平化设计给前进的道路带来了很多障碍。

想法？

Answer 1

“以读取为中心的数据库通过平面表结构显示出更好的性能。”该语句表示该表将很少/从不用于插入/更新/删除操作。在这种情况下，必须对表进行正确的索引才能获得良好的性能。由于不会有任何类型的联接，因此表将使用大量过滤器和 where 子句，因此正确使用索引非常重要。

这种场景通常用在数据仓库中。我们在设计仓库时，通常会消除主/外键，而使用业务主键。这是因为仓库里有庞大的数据库。

Answer 2

从来没有。

无论您认为通过忽略关系数据库理论要解决什么问题，您只会产生更多棘手的问题。此外，你试图通过忽略关系理论来避免的原始问题无论如何都将始终基于误解。

Answer 3

简短回答：几乎总是如此！ 您的网站几乎不需要传统数据库！

作为 IT 管理员，从事大大小小的项目 20 年之后，我可以自信地说，当今 90% 以上的网站根本不需要数据库。 这只是另一层混淆，大多数公司和个人都可以不需要。

面对事实吧。大多数网站一天内不会获得一次点击，因此对于今天（2019 年）的绝大多数网站来说，谈论数据库性能是相当愚蠢的。

这意味着超过 90% 的网站可以而且应该切换到某些平面文件 CMS/CMR，如 PageKit、Grav 或 Bludit（这是我个人最喜欢的，因为它采用简约的方法。它鄙视 flatDB 并使用普通文件夹来包含 HTML 中的文章文件。）

我从来没有弄清楚为什么像 WordPress 和 Joomla 这样的 CMS 领导者坚持通过强迫用户使用数据库连接和配置来复杂化他们的默认设置，这通常是网站故障的原因。当且仅当站点实际需要某种类型的数据库时（例如，如果它有许多用户帐户），那么数据库是有必要的。尽管如此，大多数网站只有少量的用户帐户。

很多时候，我们会看到某些站点关闭，因为数据库引擎已关闭或无法处理如此多的并发连接，而 Apache 或 NginX Web 服务器仍在启动并运行。

不要盲目跟随别人。是时候勇敢并领导了。