对于像 stackoverflow 这样的高流量网站，数据库设计和规范化的最佳做法是什么？
应该使用规范化数据库进行记录保存还是规范化技术或两者结合？
设计一个规范化的数据库作为记录保存的主数据库以减少冗余并同时维护另一种非规范化的数据库形式以进行快速搜索是否明智？
或
是否应该对主数据库进行非规范化，但在应用程序级别使用规范化视图以实现快速数据库操作？
还是其他方法？
【问题讨论】：
标签： performance database-design database-normalization high-availability denormalization
加入对性能的影响经常被高估。像 Oracle 这样的数据库产品可以非常有效地加入。当真正的罪魁祸首是糟糕的数据模型或糟糕的索引策略时，连接通常被认为表现不佳。人们还忘记了非规范化数据库在插入或更新数据时表现非常糟糕。
要记住的关键是您要构建的应用程序的类型。大多数著名的网站都不像普通的企业应用程序。这就是谷歌、Facebook 等不使用关系数据库的原因。最近有很多关于这个话题的讨论，I have blogged about。
因此，如果您要构建的网站主要是为了交付大量半结构化内容，您可能不希望使用关系数据库（非规范化或其他方式）。但是，如果您正在构建一个高度交易的网站（例如在线银行），您需要一个能够保证数据安全性和完整性的设计，并且做得很好。这意味着至少是第三范式的关系数据库。
【讨论】：
对数据库进行非规范化以减少密集查询所需的连接数是许多不同的扩展方式之一。更少的连接意味着数据库的繁重工作更少，而且磁盘很便宜。
也就是说，对于可笑的流量，很难实现良好的关系数据库性能。这就是为什么许多大型网站使用键值存储（例如 memcached）和其他缓存机制的原因。
【讨论】：
您可以在他们的播客上收听堆栈溢出的创建者关于这个主题的讨论：
http://itc.conversationsnetwork.org/shows/detail3993.html
【讨论】：
首先：为自己定义高流量的含义：
然后将其计算为每分钟和每秒可能的峰值页面浏览量。 之后考虑您要在每次页面浏览时查询的数据。数据是否可缓存？数据有多动态，数据有多大？
分析您的个人需求，编写一些代码，进行一些负载测试，优化。在大多数情况下，在您需要扩展数据库服务器之前，您需要扩展 Web 服务器。
如果完全优化，关系型数据库在连接表时可以非常快！
关系数据库很少会被用作后端来填充缓存或填充一些非规范化的数据表。我不会将非规范化作为默认方法。
（您提到了搜索，如果您需要全文搜索，请查看例如 lucene 或类似的东西。）
最好的最佳实践答案肯定是：视情况而定 ;-)
【讨论】：
对于我正在进行的一个项目，我们采用了非规范化表路径，因为我们希望我们的主要表具有较高的写入与读取比率（而不是所有用户都访问同一个表，我们已经非规范化他们并将每个“用户集”设置为使用特定的分片）。您可以阅读http://highscalability.com/ 了解“大型网站”如何应对流量的示例 - 最近精选了Stack Overflow。
【讨论】：
如果你没有正确缓存也没关系。
【讨论】：