I heard a lot about denormalization which was made to improve performance of certain application. But I've never tried to do anything related.
我听过很多关于非规范化的东西，它是为了提高某些应用的性能。但我从未尝试过做任何相关的事情。
So, I'm just curious, which places in normalized DB makes performance worse or in other words, what are denormalization principles?
我很好奇，在规范化的DB中哪些地方会使性能变差或者换句话说，什么是非规范化原则?
How can I use this technique if I need to improve performance?
如果需要提高性能，我如何使用该技术?
8 个解决方案
#1
63
Denormalization is a time-space trade-off. Normalized data takes less space, but may require join to construct the desired result set, hence more time. If it's denormalized, data are replicated in several places. It then takes more space, but the desired view of the data is readily available.
非规范化是一种时间-空间的权衡。规范化数据占用的空间更少，但可能需要连接来构建所需的结果集，因此需要更多时间。如果非规范化，数据将在多个地方复制。然后它会占用更多的空间，但是所需的数据视图很容易获得。
There are other time-space optimizations, such as
还有其他时间空间优化，例如
- denormalized view
- 规范化的视图
- precomputed columns
- 预先计算的列
As with any of such approach, this improves reading data (because they are readily available), but updating data becomes more costly (because you need to update the replicated or precomputed data).
与任何此类方法一样，这将改进读取数据(因为它们很容易获得)，但是更新数据会变得更昂贵(因为您需要更新复制的或预计算的数据)。
#2
76
Denormalization is generally used to either:
非规范化通常用于以下两种情况:
- Avoid a certain number of queries
- 避免一定数量的查询
- Remove some joins
- 删除一些连接
The basic idea of denormalization is that you'll add redundant data, or group some, to be able to get those data more easily -- at a smaller cost; which is better for performances.
非规范化的基本思想是，你将添加冗余数据，或者将一些数据分组，以更容易地获取这些数据——以更小的成本;这对表演来说更好。
A quick examples?
一个快速的例子吗?
- Consider a "Posts" and a "Comments" table, for a blog
- For each Post, you'll have several lines in the "Comment" table
- 对于每个帖子，在“评论”表中都有几行
- This means that to display a list of posts with the associated number of comments, you'll have to:
- Do one query to list the posts
- 做一个查询来列出文章
- Do one query per post to count how many comments it has (Yes, those can be merged into only one, to get the number for all posts at once)
- 每个帖子做一个查询，计算它有多少条评论(是的，这些评论可以合并为一个，一次获得所有帖子的数量)
- Which means several queries.
- 这意味着几个查询。
- 这意味着显示文章列表数量相关的评论,你需要:一个查询列出文章做一个查询每个帖子数有多少评论(是的,这些只能合并成一个,立刻让所有帖子的数量)这意味着一些查询。
- 考虑一个“职位”和“评论”表,为每一个博客帖子,你会有几行“评论”表中这意味着显示文章列表数量相关的评论,你需要:一个查询列出文章做一个查询每个帖子数有多少评论(是的,这些只能合并成一个,立刻让所有帖子的数量)这意味着一些查询。
- Now, if you add a "number of comments" field into the Posts table:
- You only need one query to list the posts
- 您只需要一个查询就可以列出文章
- And no need to query the Comments table: the number of comments are already de-normalized to the Posts table.
- 而且不需要查询Comments表:注释的数量已经在Posts表中被取消规范化。
- And only one query that returns one more field is better than more queries.
- 只有一个查询返回一个字段比多个查询更好。
- 现在，如果您在Posts表中添加了“number of comments”字段:您只需要一个查询就可以列出这些post，不需要查询comments表:comments表的注释数量已经被反规范化了。只有一个查询返回一个字段比多个查询更好。
Now, there are some costs, yes:
现在，有一些成本，是的:
- First, this costs some place on both disk and in memory, as you have some redundant informations:
- The number of comments are stored in the Posts table
- 注释的数量存储在Posts表中
- And you can also find those number counting on the Comments table
- 你也可以在Comments表上找到这些数字
- 首先，这在磁盘和内存中都要付出一定的代价，因为您有一些冗余信息:注释的数量存储在Posts表中，您还可以在comments表中找到这些数字
- Second, each time someone adds/removes a comment, you have to:
- Save/delete the comment, of course
- 当然，保存/删除评论。
- But also, update the corresponding number in the Posts table.
- 但是，还要更新Posts表中的相应数字。
- But, if your blog has a lot more people reading than writing comments, this is probably not so bad.
- 但是，如果你的博客有更多的人在阅读而不是写评论，这可能不是那么糟糕。
- 其次，每当有人添加/删除评论时，您必须:保存/删除评论，当然，还要更新Posts表中的相应数字。但是，如果你的博客有更多的人在阅读而不是写评论，这可能不是那么糟糕。
#3
11
The word "denormalizing" leads to confusion of the design issues. Trying to get a high performance database by denormalizing is like trying to get to your destination by driving away from New York. It doesn't tell you which way to go.
“非规范化”一词会导致设计问题的混乱。通过非规范化来获取高性能数据库，就像开车离开纽约去目的地一样。它没有告诉你该走哪条路。
What you need is a good design discipline, one that produces a simple and sound design, even if that design sometimes conflicts with the rules of normalization.
您需要的是一个良好的设计规程，一个能够产生简单而合理的设计的规程，即使这个设计有时与规范化的规则相冲突。
One such design discipline is star schema. In a star schema, a single fact table serves as the hub of a star of tables. The other tables are called dimension tables, and they are at the rim of the schema. The dimensions are connected to the fact table by relationships that look like the spokes of a wheel. Star schema is basically a way of projecting multidimensional design onto an SQL implementation.
星型模式就是其中之一。在星型模式中，单个事实表充当表星形的中心。其他表称为维度表，它们位于模式的边缘。维度通过看起来像车轮辐条的关系连接到事实表。星型模式基本上是将多维设计投影到SQL实现上的一种方法。
Closely related to star schema is snowflake schema, which is a little more complicated.
与星型模式密切相关的是雪花模式，这有点复杂。
If you have a good star schema, you will be able to get a huge variety of combinations of your data with no more than a three way join, involving two dimensions and one fact table. Not only that, but many OLAP tools will be able to decipher your star design automatically, and give you point-and-click, drill down, and graphical analysis access to your data with no further programming.
如果您有一个良好的星型模式，您将能够获得大量的数据组合，这些组合不超过3路连接，包括两个维度和一个事实表。不仅如此，许多OLAP工具将能够自动识别您的星型设计，并给您点-点击、钻取和图形分析访问您的数据，而无需进一步编程。
Star schema design occasionally violates second and third normal forms, but it results in more speed and flexibility for reports and extracts. It's most often used in data warehouses, data marts, and reporting databases. You'll generally have much better results from star schema or some other retrieval oriented design, than from just haphazard "denormalization".
星型模式设计偶尔会违反第二和第三种常规形式，但它会提高报告和摘录的速度和灵活性。它通常用于数据仓库、数据集市和报告数据库。通常，从星型模式或其他面向检索的设计中，您会得到比随意的“非规范化”更好的结果。
#4
7
The critical issues in denormalizing are:
非规范化的关键问题是:
- Deciding what data to duplicate and why
- 决定要复制什么数据以及为什么要复制
- Planning how to keep the data in synch
- 计划如何保持数据同步
- Refactoring the queries to use the denormalized fields.
- 重构查询以使用非规范化字段。
One of the easiest types of denormalizing is to populate an identity field to tables to avoid a join. As identities should not ever change, this means the issue of keeping the data in sync rarely comes up. For instance, we populate our client id to several tables because we often need to query them by client and do not necessarily need, in the queries, any of the data in the tables that would be between the client table and the table we are querying if the data was totally normalized. You still have to do one join to get the client name, but that is better than joining to 6 parent tables to get the client name when that is the only piece of data you need from outside the table you are querying.
反规范化最简单的类型之一是将标识字段填充到表中，以避免联接。由于身份不应该改变，这意味着保持数据同步的问题很少出现。例如,填充我们的客户机id几个表,因为我们经常需要由客户端,不一定需要查询,在查询,任何客户端之间的数据表中,表和表我们查询如果完全规范化的数据。您仍然需要执行一个连接来获取客户端名称，但这比连接到6个父表来获取客户端名称要好，因为这是您要查询的表之外惟一需要的数据。
However, there would be no benefit to this unless we were often doing queries where data from the intervening tables was needed.
然而，除非我们经常在需要来自中间表的数据的地方执行查询，否则这样做没有任何好处。
Another common denormalization might be to add a name field to other tables. As names are inherently changeable, you need to ensure that the names stay in synch with triggers. But if this saves you from joining to 5 tables instead of 2, it can be worth the cost of the slightly longer insert or update.
另一个常见的非规范化可能是向其他表添加一个name字段。由于名称本身是可变的，您需要确保名称与触发器保持同步。但是，如果这样可以避免加入5个表而不是2个表，那么稍微长一点的插入或更新的成本是值得的。
#5
3
If you have certain requirement, like reporting etc., it can help to denormalize your database in various ways:
如果您有特定的需求，如报告等，它可以帮助您以各种方式去反规范化数据库:
-
introduce certain data duplication to save yourself some JOINs (e.g. fill certain information into a table and be ok with duplicated data, so that all the data in that table and doesn't need to be found by joining another table)
引入特定的数据复制来保存一些连接(例如，将某些信息填充到一个表中，并对重复的数据进行处理，以便该表中的所有数据不需要通过连接另一个表来找到)
-
you can pre-compute certain values and store them in a table column, insteda of computing them on the fly, everytime to query the database. Of course, those computed values might get "stale" over time and you might need to re-compute them at some point, but just reading out a fixed value is typically cheaper than computing something (e.g. counting child rows)
您可以预先计算某些值并将它们存储在一个表列中，而不是动态地计算它们，以便每次查询数据库。当然，随着时间的推移，这些计算值可能会变得“过时”，您可能需要在某些时候重新计算它们，但是仅仅读出一个固定的值通常比计算一些东西(例如，计算子行)要便宜。
There are certainly more ways to denormalize a database schema to improve performance, but you just need to be aware that you do get yourself into a certain degree of trouble doing so. You need to carefully weigh the pros and cons - the performance benefits vs. the problems you get yourself into - when making those decisions.
当然，还有更多的方法可以去规格化数据库模式以提高性能，但是您只需要知道这样做确实会给您自己带来一定的麻烦。当你做出这些决定时，你需要仔细权衡利弊——绩效收益和你所面临的问题。
#6
1
Consider a database with a properly normalized parent-child relationship.
考虑一个具有适当规范化的父子关系的数据库。
Let's say the cardinality is an average of 2x1.
假设基数是2x1的平均值。
You have two tables, Parent, with p rows. Child with 2x p rows.
有两个表，父表，有p行。具有2x p行的子元素。
The join operation means for p parent rows, 2x p child rows must be read. The total number of rows read is p + 2x p.
join操作意味着对于p父行，必须读取2x p子行。读取的行总数是p + 2x p。
Consider denormalizing this into a single table with only the child rows, 2x p. The number of rows read is 2x p.
考虑将它反规范化为一个只有子行2x p的表。读取的行数是2x p。
Fewer rows == less physical I/O == faster.
更少的行=更少的物理I/O =更快。
#7
0
As per the last section of this article,
根据本文的最后一节，
https://technet.microsoft.com/en-us/library/aa224786%28v=sql.80%29.aspx
https://technet.microsoft.com/en-us/library/aa224786%28v=sql.80%29.aspx
one could use Virtual Denormalization, where you create Views with some denormalized data for running more simplistic SQL queries faster, while the underlying Tables remain normalized for faster add/update operations (so long as you can get away with updating the Views at regular intervals rather than in real-time). I'm just taking a class on Relational Databases myself but, from what I've been reading, this approach seems logical to me.
我们可以使用虚拟的反规范化，在这里，您可以用一些非规范化的数据创建视图，以便更快地运行更简单的SQL查询，而底层表仍然是规范化的，以便更快地添加/更新操作(只要您不需要实时地更新视图，就可以得到更新)。我自己也在上关系数据库的课程，但是，从我读到的内容来看，这种方法对我来说似乎是合乎逻辑的。
#8
-6
Benefits of de-normalization over normalization
反规范化优于规范化
Basically de-normalization is used for DBMS not for RDBMS. As we know that RDBMS works with normalization, which means no repeat data again and again. But still repeat some data when you use foreign key.
基本上，非规范化用于DBMS而不是RDBMS。正如我们所知道的，RDBMS支持规范化，这意味着不会重复数据。但是当你使用外键时还是要重复一些数据。
When you use DBMS then there is a need to remove normalization. For this, there is a need for repetition. But still, it improves performance because there is no relation among the tables and each table has indivisible existence.
当您使用DBMS时，需要删除规范化。为此，需要重复。但是，它仍然可以提高性能，因为表和每个表之间没有关系。
#1
63
Denormalization is a time-space trade-off. Normalized data takes less space, but may require join to construct the desired result set, hence more time. If it's denormalized, data are replicated in several places. It then takes more space, but the desired view of the data is readily available.
非规范化是一种时间-空间的权衡。规范化数据占用的空间更少，但可能需要连接来构建所需的结果集，因此需要更多时间。如果非规范化，数据将在多个地方复制。然后它会占用更多的空间，但是所需的数据视图很容易获得。
There are other time-space optimizations, such as
还有其他时间空间优化，例如
- denormalized view
- 规范化的视图
- precomputed columns
- 预先计算的列
As with any of such approach, this improves reading data (because they are readily available), but updating data becomes more costly (because you need to update the replicated or precomputed data).
与任何此类方法一样，这将改进读取数据(因为它们很容易获得)，但是更新数据会变得更昂贵(因为您需要更新复制的或预计算的数据)。
#2
76
Denormalization is generally used to either:
非规范化通常用于以下两种情况:
- Avoid a certain number of queries
- 避免一定数量的查询
- Remove some joins
- 删除一些连接
The basic idea of denormalization is that you'll add redundant data, or group some, to be able to get those data more easily -- at a smaller cost; which is better for performances.
非规范化的基本思想是，你将添加冗余数据，或者将一些数据分组，以更容易地获取这些数据——以更小的成本;这对表演来说更好。
A quick examples?
一个快速的例子吗?
- Consider a "Posts" and a "Comments" table, for a blog
- For each Post, you'll have several lines in the "Comment" table
- 对于每个帖子，在“评论”表中都有几行
- This means that to display a list of posts with the associated number of comments, you'll have to:
- Do one query to list the posts
- 做一个查询来列出文章
- Do one query per post to count how many comments it has (Yes, those can be merged into only one, to get the number for all posts at once)
- 每个帖子做一个查询，计算它有多少条评论(是的，这些评论可以合并为一个，一次获得所有帖子的数量)
- Which means several queries.
- 这意味着几个查询。
- 这意味着显示文章列表数量相关的评论,你需要:一个查询列出文章做一个查询每个帖子数有多少评论(是的,这些只能合并成一个,立刻让所有帖子的数量)这意味着一些查询。
- 考虑一个“职位”和“评论”表,为每一个博客帖子,你会有几行“评论”表中这意味着显示文章列表数量相关的评论,你需要:一个查询列出文章做一个查询每个帖子数有多少评论(是的,这些只能合并成一个,立刻让所有帖子的数量)这意味着一些查询。
- Now, if you add a "number of comments" field into the Posts table:
- You only need one query to list the posts
- 您只需要一个查询就可以列出文章
- And no need to query the Comments table: the number of comments are already de-normalized to the Posts table.
- 而且不需要查询Comments表:注释的数量已经在Posts表中被取消规范化。
- And only one query that returns one more field is better than more queries.
- 只有一个查询返回一个字段比多个查询更好。
- 现在，如果您在Posts表中添加了“number of comments”字段:您只需要一个查询就可以列出这些post，不需要查询comments表:comments表的注释数量已经被反规范化了。只有一个查询返回一个字段比多个查询更好。
Now, there are some costs, yes:
现在，有一些成本，是的:
- First, this costs some place on both disk and in memory, as you have some redundant informations:
- The number of comments are stored in the Posts table
- 注释的数量存储在Posts表中
- And you can also find those number counting on the Comments table
- 你也可以在Comments表上找到这些数字
- 首先，这在磁盘和内存中都要付出一定的代价，因为您有一些冗余信息:注释的数量存储在Posts表中，您还可以在comments表中找到这些数字
- Second, each time someone adds/removes a comment, you have to:
- Save/delete the comment, of course
- 当然，保存/删除评论。
- But also, update the corresponding number in the Posts table.
- 但是，还要更新Posts表中的相应数字。
- But, if your blog has a lot more people reading than writing comments, this is probably not so bad.
- 但是，如果你的博客有更多的人在阅读而不是写评论，这可能不是那么糟糕。
- 其次，每当有人添加/删除评论时，您必须:保存/删除评论，当然，还要更新Posts表中的相应数字。但是，如果你的博客有更多的人在阅读而不是写评论，这可能不是那么糟糕。
#3
11
The word "denormalizing" leads to confusion of the design issues. Trying to get a high performance database by denormalizing is like trying to get to your destination by driving away from New York. It doesn't tell you which way to go.
“非规范化”一词会导致设计问题的混乱。通过非规范化来获取高性能数据库，就像开车离开纽约去目的地一样。它没有告诉你该走哪条路。
What you need is a good design discipline, one that produces a simple and sound design, even if that design sometimes conflicts with the rules of normalization.
您需要的是一个良好的设计规程，一个能够产生简单而合理的设计的规程，即使这个设计有时与规范化的规则相冲突。
One such design discipline is star schema. In a star schema, a single fact table serves as the hub of a star of tables. The other tables are called dimension tables, and they are at the rim of the schema. The dimensions are connected to the fact table by relationships that look like the spokes of a wheel. Star schema is basically a way of projecting multidimensional design onto an SQL implementation.
星型模式就是其中之一。在星型模式中，单个事实表充当表星形的中心。其他表称为维度表，它们位于模式的边缘。维度通过看起来像车轮辐条的关系连接到事实表。星型模式基本上是将多维设计投影到SQL实现上的一种方法。
Closely related to star schema is snowflake schema, which is a little more complicated.
与星型模式密切相关的是雪花模式，这有点复杂。
If you have a good star schema, you will be able to get a huge variety of combinations of your data with no more than a three way join, involving two dimensions and one fact table. Not only that, but many OLAP tools will be able to decipher your star design automatically, and give you point-and-click, drill down, and graphical analysis access to your data with no further programming.
如果您有一个良好的星型模式，您将能够获得大量的数据组合，这些组合不超过3路连接，包括两个维度和一个事实表。不仅如此，许多OLAP工具将能够自动识别您的星型设计，并给您点-点击、钻取和图形分析访问您的数据，而无需进一步编程。
Star schema design occasionally violates second and third normal forms, but it results in more speed and flexibility for reports and extracts. It's most often used in data warehouses, data marts, and reporting databases. You'll generally have much better results from star schema or some other retrieval oriented design, than from just haphazard "denormalization".
星型模式设计偶尔会违反第二和第三种常规形式，但它会提高报告和摘录的速度和灵活性。它通常用于数据仓库、数据集市和报告数据库。通常，从星型模式或其他面向检索的设计中，您会得到比随意的“非规范化”更好的结果。
#4
7
The critical issues in denormalizing are:
非规范化的关键问题是:
- Deciding what data to duplicate and why
- 决定要复制什么数据以及为什么要复制
- Planning how to keep the data in synch
- 计划如何保持数据同步
- Refactoring the queries to use the denormalized fields.
- 重构查询以使用非规范化字段。
One of the easiest types of denormalizing is to populate an identity field to tables to avoid a join. As identities should not ever change, this means the issue of keeping the data in sync rarely comes up. For instance, we populate our client id to several tables because we often need to query them by client and do not necessarily need, in the queries, any of the data in the tables that would be between the client table and the table we are querying if the data was totally normalized. You still have to do one join to get the client name, but that is better than joining to 6 parent tables to get the client name when that is the only piece of data you need from outside the table you are querying.
反规范化最简单的类型之一是将标识字段填充到表中，以避免联接。由于身份不应该改变，这意味着保持数据同步的问题很少出现。例如,填充我们的客户机id几个表,因为我们经常需要由客户端,不一定需要查询,在查询,任何客户端之间的数据表中,表和表我们查询如果完全规范化的数据。您仍然需要执行一个连接来获取客户端名称，但这比连接到6个父表来获取客户端名称要好，因为这是您要查询的表之外惟一需要的数据。
However, there would be no benefit to this unless we were often doing queries where data from the intervening tables was needed.
然而，除非我们经常在需要来自中间表的数据的地方执行查询，否则这样做没有任何好处。
Another common denormalization might be to add a name field to other tables. As names are inherently changeable, you need to ensure that the names stay in synch with triggers. But if this saves you from joining to 5 tables instead of 2, it can be worth the cost of the slightly longer insert or update.
另一个常见的非规范化可能是向其他表添加一个name字段。由于名称本身是可变的，您需要确保名称与触发器保持同步。但是，如果这样可以避免加入5个表而不是2个表，那么稍微长一点的插入或更新的成本是值得的。
#5
3
If you have certain requirement, like reporting etc., it can help to denormalize your database in various ways:
如果您有特定的需求，如报告等，它可以帮助您以各种方式去反规范化数据库:
-
introduce certain data duplication to save yourself some JOINs (e.g. fill certain information into a table and be ok with duplicated data, so that all the data in that table and doesn't need to be found by joining another table)
引入特定的数据复制来保存一些连接(例如，将某些信息填充到一个表中，并对重复的数据进行处理，以便该表中的所有数据不需要通过连接另一个表来找到)
-
you can pre-compute certain values and store them in a table column, insteda of computing them on the fly, everytime to query the database. Of course, those computed values might get "stale" over time and you might need to re-compute them at some point, but just reading out a fixed value is typically cheaper than computing something (e.g. counting child rows)
您可以预先计算某些值并将它们存储在一个表列中，而不是动态地计算它们，以便每次查询数据库。当然，随着时间的推移，这些计算值可能会变得“过时”，您可能需要在某些时候重新计算它们，但是仅仅读出一个固定的值通常比计算一些东西(例如，计算子行)要便宜。
There are certainly more ways to denormalize a database schema to improve performance, but you just need to be aware that you do get yourself into a certain degree of trouble doing so. You need to carefully weigh the pros and cons - the performance benefits vs. the problems you get yourself into - when making those decisions.
当然，还有更多的方法可以去规格化数据库模式以提高性能，但是您只需要知道这样做确实会给您自己带来一定的麻烦。当你做出这些决定时，你需要仔细权衡利弊——绩效收益和你所面临的问题。
#6
1
Consider a database with a properly normalized parent-child relationship.
考虑一个具有适当规范化的父子关系的数据库。
Let's say the cardinality is an average of 2x1.
假设基数是2x1的平均值。
You have two tables, Parent, with p rows. Child with 2x p rows.
有两个表，父表，有p行。具有2x p行的子元素。
The join operation means for p parent rows, 2x p child rows must be read. The total number of rows read is p + 2x p.
join操作意味着对于p父行，必须读取2x p子行。读取的行总数是p + 2x p。
Consider denormalizing this into a single table with only the child rows, 2x p. The number of rows read is 2x p.
考虑将它反规范化为一个只有子行2x p的表。读取的行数是2x p。
Fewer rows == less physical I/O == faster.
更少的行=更少的物理I/O =更快。
#7
0
As per the last section of this article,
根据本文的最后一节，
https://technet.microsoft.com/en-us/library/aa224786%28v=sql.80%29.aspx
https://technet.microsoft.com/en-us/library/aa224786%28v=sql.80%29.aspx
one could use Virtual Denormalization, where you create Views with some denormalized data for running more simplistic SQL queries faster, while the underlying Tables remain normalized for faster add/update operations (so long as you can get away with updating the Views at regular intervals rather than in real-time). I'm just taking a class on Relational Databases myself but, from what I've been reading, this approach seems logical to me.
我们可以使用虚拟的反规范化，在这里，您可以用一些非规范化的数据创建视图，以便更快地运行更简单的SQL查询，而底层表仍然是规范化的，以便更快地添加/更新操作(只要您不需要实时地更新视图，就可以得到更新)。我自己也在上关系数据库的课程，但是，从我读到的内容来看，这种方法对我来说似乎是合乎逻辑的。
#8
-6
Benefits of de-normalization over normalization
反规范化优于规范化
Basically de-normalization is used for DBMS not for RDBMS. As we know that RDBMS works with normalization, which means no repeat data again and again. But still repeat some data when you use foreign key.
基本上，非规范化用于DBMS而不是RDBMS。正如我们所知道的，RDBMS支持规范化，这意味着不会重复数据。但是当你使用外键时还是要重复一些数据。
When you use DBMS then there is a need to remove normalization. For this, there is a need for repetition. But still, it improves performance because there is no relation among the tables and each table has indivisible existence.
当您使用DBMS时，需要删除规范化。为此，需要重复。但是，它仍然可以提高性能，因为表和每个表之间没有关系。