现在什么时候可以使用平面db表设计呢？有过吗？我的意思是，当我们应该为另一个表创建一个键以存储多行时，什么时候可以放弃关系数据库设计的智慧，恢复不包含链接的平面表结构，添加额外的列以添加更多数据。
我正在研究一些与产品管理团队讨论的想法。当我最初问“为什么这些桌子都是平的”时，我被告知
“以读为中心的数据库使用平面表结构显示更好的性能。”
我很难解释这一点。一个扁平的设计给我们的发展带来了很多障碍。
思想？
最佳答案
“以读为中心的数据库使用平面表结构显示更好的性能。”这句话说表不会/很少用于插入/更新/删除操作。在这种情况下，必须正确索引表才能获得良好的性能。因为不会有任何类型的连接，所以表将在WHERE子句中使用大量的过滤器，因此索引是非常重要的，可以被适当地使用。
这种场景通常用于数据仓库。在设计仓库时，我们通常会消除主键/外键，并使用业务主键。这是因为仓库里有庞大的数据库。
关于database - 何时可以接受平面DB设计，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/13959584/