我有一个数据库，它将构成一个高流量网络应用程序的一部分。
我想知道是否应该对表格进行规范化，以便（例如）“question_type”之类的内容也应该放在单独的表格中，以及有关问题的所有基本信息，例如“title”和“question_body”？
我之所以这么问，是因为我需要这个数据库尽可能地具有可扩展性，而且有人告诉我，当您需要可扩展性时，规范化并不总是可行的方法。
谢谢
【问题讨论】：
标签： database scalability normalization
使标准化成为缩放问题的原因在于它往往需要将多个表连接在一起。连接在小表上非常有用，但表越大，服务器就越需要工作。
要注意的主要事情是避免连接。如果您可以通过将字段添加到其中一个表来执行不使用连接的查询，那么您只需加快该查询的性能。
【讨论】：
如果您的表有question_body 和question_type，那么我看不出将其移至另一个表如何实现规范化。例如：
table question (
question_body text,
question_user text,
question_user_rank integer,
question_type text
);
将单个值拆分为单个列表除了无用的连接之外不会实现任何其他功能。那就是：
select * from question q join question_type qt on (q.qt_id = qt.id)
where qt.name = 'sql questions';
是一个等价的，但浪费的形式
select * from question
where question_type = 'sql questions';
另一方面，（使用上面的示例），将问题用户信息拆分到自己的表中是很有意义的：
table question (
question_body text,
question_type text,
question_user_id integer references question_user(id) on delete cascade
);
table question_user (
id integer,
name text,
rank integer
);
因此，如果用户更改了他的排名（ala SO），您只需在一个地方更改它，而不是在他被问问题的每一行中进行更改。由于您将数百个更新更改为一个更新，因此您提高了处理缩放的能力。
【讨论】：
现在这是一个加载的问题。规范化与其说是一条硬性规则，不如说是一种指导方针。设计数据库由一系列关于规范化级别的决策组成，考虑到您对代码效率、性能和完整性等的需求，这些决策是有意义的。这大大简化了它，但设计决策的范围涵盖了大量的优秀书籍。
您能告诉我更多关于您的应用程序和预期平台的信息吗？如果我能更好地了解您的情况，我可能会引导您了解一些非常有用的参考资料。
【讨论】：
加盐会让我的食物味道更好吗？
同样的问题。没人能回答。
主要问题是它取决于您的使用模式以及您作为程序员的能力，在应用程序中使用查找缓存而不是数据库连接。相当多的程序员从来没有超过 SQL 的“炒鸡蛋，烧焦”级别，以保持烹饪类比。
对于可扩展性应用程序设计和数据库技术还有很多话要说。难以击败 Oracle RAC 安装。取决于您在 Exadata 平台上的需要。我认为最小单位的成本约为 50 万美元。仍然确定您需要“尽可能可扩展”吗？不是在开玩笑 - 我现在在一个 6000 GB 的数据仓库上工作，我们只订购了 3 个这样的怪物，而不是最小的一个。
那么，“尽可能可扩展”是什么意思？这就像“我的车需要开得和以前的车一样快”，然后你最终会得到一辆装有喷气发动机的特制汽车；）
一般规则： * 将交易和报告分离到两个数据库中。第二个是数据仓库。 * 规范化事务数据库 * 在数据仓库中使用星型模式。
很大的机会是：你不知道你在说什么，从来没有做过可伸缩性，所以你的“高可伸缩性”要求有 80% 的可能性是一个像样的数据库服务器的笑话。现在，这并不意味着侮辱，但我看到很多人说“我在一个表中有大量数据”，这变成了最多 10.000 行。这不是一吨 - 这是一个笑话。我们每天将 1 亿个加载到我们的数据仓库主表中（并且必须保留它们很多年）。大多数人并没有真正获得像样的数据库服务器可以提供的速度。这意味着许多光盘。
【讨论】：