现在什么时候可以使用平面 DB 表设计。曾经？我的意思是什么时候可以放弃关系数据库设计的智慧并恢复一个不包含链接的平面表结构，添加额外的列来添加更多数据，什么时候我们应该创建另一个表的键来存储多行.
我正在研究一些想法，与产品管理团队讨论。当我最初问“为什么所有这些表本质上都是扁平的”这个问题时，我被告知“以读取为中心的数据库在扁平表结构中表现出更好的性能”。
我对这种解释感到困惑，b/ca 平面设计在未来的道路上存在许多障碍。
想法？
问问题
1620 次
3 回答
3
“以读取为中心的数据库通过扁平表结构显示出更好的性能。” 该语句表示表不会/很少用于插入/更新/删除操作。在这种情况下，必须正确索引表以获得良好的性能。由于不会有任何类型的连接，因此表将在 where 子句中使用大量过滤器，因此正确使用索引非常重要。
这种场景通常用在数据仓库中。我们在设计仓库的时候，通常会去掉主键/外键，使用业务主键。这是因为仓库中有庞大的数据库。
于 2012-12-19T19:27:40.437 回答
0
绝不。
无论您认为通过忽略关系数据库理论来解决什么问题，您只会产生更多棘手的问题。此外，您试图通过忽略关系理论来避免的原始问题无论如何都将始终基于误解。
于 2012-12-22T20:47:05.090 回答
0
简短的回答：几乎总是！您的网站几乎不需要传统数据库！
作为一名 IT 管理员工作了 20 年，从事过大大小小的项目，我可以自信地说，当今 90% 以上的网站根本不需要数据库。这只是大多数公司和人们可以不用的另一层混淆。
面对事实的人。那里的大多数网站一天都没有受到一次点击，所以当谈到今天（2019 年）的绝大多数网站时，谈论数据库性能是非常愚蠢的。
这意味着超过 90% 的这些站点可以并且应该切换到一些平面文件 CMS/CMR，例如 PageKit、Grav 或 Bludit（这是我个人最喜欢的，因为它采用简约的方法。它不屑一顾 flatDB 并使用普通文件夹来包含 HTML 文件中的文章.)
我从来没有弄清楚为什么像 WordPress 和 Joomla 这样的 CMS 领导者坚持通过强迫他们的用户使用数据库连接和配置来使他们的默认设置复杂化，这通常是网站出现故障的原因。当且仅当站点实际上需要某种类型的数据库时，例如如果它有许多用户帐户，那么数据库是有保证的。尽管如此，大多数网站只有一个完整的用户帐户。
很多时候，我们看到一些站点关闭，因为数据库引擎关闭或无法处理这么多的同时连接，而 Apache 或 NginX 网络服务器仍在运行。
不要只是盲目地跟随别人。是时候勇敢和领导了。
于 2019-08-09T08:57:10.870 回答