当您考虑连接的复杂性类时，决定是去规范化还是规范化是相当简单的过程。例如，当查询为O(k log n)时，我倾向于用规范化设计数据库，其中k相对于所需的输出大小。

反规格化和优化性能的一个简单方法是考虑对规范化结构的更改如何影响反规格化结构。然而，这可能会有问题，因为它可能需要事务逻辑才能在非规范化的结构化上工作。

关于正常化和非正常化的争论不会结束，因为问题是巨大的。许多问题的自然解决方案需要两种方法。

作为一般规则，我总是存储可以重构的规范化结构和非规范化缓存。最终，这些缓存帮我解决了未来的规范化问题。

大多数评论者没有注意到的是，在复杂的RDBMS中可以使用广泛的连接方法，而非规范化者总是掩盖维护非规范化数据的更高成本。并不是每个连接都基于索引，数据库有许多用于连接的优化算法和方法，旨在降低连接成本。

在任何情况下，连接的成本取决于它的类型和其他一些因素。它一点也不贵——举个例子。

A hash join, in which bulk data is equijoined, is very cheap indeed, and the cost only become significant if the hash table cannot be cached in memory. No index required. Equi-partitioning between the joined data sets can be a great help. The cost of a sort-merge join is driven by the cost of the sort rather than the merge -- an index-based access method can virtually eliminate the cost of the sort. The cost of a nested loop join on an index is driven by the height of the b-tree index and the access of the table block itself. It's fast, but not suitable for bulk joins. A nested loop join based on a cluster is much cheaper, with fewer logicAL IO'S required per join row -- if the joined tables are both in the same cluster then the join becomes very cheap through the colocation of joined rows.

数据库是为连接而设计的，它们在如何进行连接方面非常灵活，通常性能非常好，除非连接机制出错。

当您考虑连接的复杂性类时，决定是去规范化还是规范化是相当简单的过程。例如，当查询为O(k log n)时，我倾向于用规范化设计数据库，其中k相对于所需的输出大小。

反规格化和优化性能的一个简单方法是考虑对规范化结构的更改如何影响反规格化结构。然而，这可能会有问题，因为它可能需要事务逻辑才能在非规范化的结构化上工作。

关于正常化和非正常化的争论不会结束，因为问题是巨大的。许多问题的自然解决方案需要两种方法。

作为一般规则，我总是存储可以重构的规范化结构和非规范化缓存。最终，这些缓存帮我解决了未来的规范化问题。

瓶颈几乎总是磁盘I/O，甚至更具体地说——随机磁盘I/O(相比之下，顺序读取相当快，可以使用预读策略进行缓存)。

连接可以增加随机搜索——如果你在一个大表中跳跃读取一小部分。但是，如果查询优化器认为这样更好的话，它会将其转换为顺序表扫描(丢弃不需要的行)。

A single denormalized table has a similar problem - the rows are large, and so less fit on a single data page. If you need rows that are located far from another (and the large row size makes them further apart) then you'll have more random I/O. Again, a table scan may be forced to avoid this. But, this time, your table scan has to read more data because of the large row size. Add to that the fact that you're copying data from a single location to multiple locations, and the RDBMS has that much more to read (and cache).

对于2个表，您还可以获得2个聚集索引—并且通常可以索引更多(因为插入/更新开销更少)，这可以极大地提高性能(主要是因为索引(相对)较小，可以快速从磁盘读取(或缓存成本低)，并减少需要从磁盘读取的表行数量)。

联接的唯一开销来自于计算匹配的行。Sql Server使用3种不同类型的连接(主要基于数据集大小)来查找匹配的行。如果优化器选择了错误的连接类型(由于统计数据不准确、索引不足，或者只是优化器错误或边缘情况)，就会极大地影响查询时间。

A loop join is farily cheap for (at least 1) small dataset. A merge join requires a sort of both datasets first. If you join on an indexed column, though, then the index is already sorted and no further work needs to be done. Otherwise, there is some CPU and memory overhead in sorting. The hash join requires both memory (to store the hashtable) and CPU (to build the hash). Again, this is fairly quick in relation to the disk I/O. However, if there's not enough RAM to store the hashtable, Sql Server will use tempdb to store parts of the hashtable and the found rows, and then process only parts of the hashtable at a time. As with all things disk, this is fairly slow.

在最佳情况下，这些操作不会导致磁盘I/O，因此从性能角度看可以忽略不计。

总之，在最坏的情况下——从x个连接表中读取相同数量的逻辑数据实际上应该比从单个非规格化表中读取更快，因为磁盘读取更小。要读取相同数量的物理数据，可能会有一些轻微的开销。

由于查询时间通常由I/O成本决定，并且数据的大小不会因非规范化而改变(减去一些非常微小的行开销)，因此仅仅将表合并在一起并没有巨大的好处。倾向于提高性能的非规范化类型IME是缓存计算值，而不是读取计算这些值所需的10,000行。

I think the whole question is based on a false premise. Joins on large tables are not necessarily expensive. In fact, doing joins efficiently is one of the main reasons relational databases exist at all. Joins on large sets often are expensive, but very rarely do you want to join the entire contents of large table A with the entire contents of large table B. Instead, you write the query such that only the important rows of each table are used and the actual set kept by the join remains smaller.

此外，您还具有Peter Wone提到的效率，这样在最终结果集物化之前，每条记录的重要部分只需要存储在内存中。此外，在具有许多连接的大型查询中，您通常希望从较小的表集开始，然后逐步到较大的表集，以便内存中保留的表集尽可能长时间地保持较小。

如果操作得当，联接通常是比较、组合或筛选大量数据的最佳方式。

连接表的顺序非常重要。如果您有两组数据，请尝试以一种方式构建查询，因此将首先使用最小的数据，以减少查询必须处理的数据量。

对于一些数据库来说，这并不重要，例如MS SQL在大多数情况下知道正确的连接顺序。 对于某些(如IBM Informix)来说，顺序决定了一切。