性能表（多查询vs单个大查询）的表格布局

我正在做一个使用MySQL的Web应用程序，而且我正在设计它。我只是有一个关于性能的小问题。

我想知道什么是更有效的：

方案1：

Table: Restaurant 
    -Name 
    -City 
    -Province 
    -Country 
    -Continent 

sql =~ select * from restaurant where id = something.

或

方案2：

Table: Restaurant 
    -Name 
    -City 
Table: City 
    -Name 
    -Province 
Table: Province 
    -Name 
    -Country 
Table: Country 
    -Name 
    -Continent 
Table: Continent 
    -Name 

sql =~ [insert multiple sql queries that will output the name and the city, 
     with the corresponding province, country, and continent]

从逻辑上讲，我认为场景＃1更好（更少查询），但有些人否则穿给我。

来源

2009-10-15 Aktee

是的，但问题在于哪个选项性能更好。在这种情况下，毫无疑问：由于查询不必与任何其他表联接，选项＃1的性能会更好。 Randolph确实有一个好处，只要有可能，你应该规范你的数据库结构。

来源

2009-10-15 06:57:53

感谢您的快速回复。我将阅读有关规范化数据库结构的文章，因为我现在不太了解这个概念。 – Aktee 2009-10-15 07:08:47

+1。选项1一定会更快。（但这并不意味着它很好）。它肯定会帮助你，Aktee，了解正常化的优点/缺点（我已经学会了这种痛苦的方式：D） – putolaruan 2009-10-15 07:10:55

谢谢你们，我将使用规范化的数据库。从我读到的内容来看，我不认为性能增益值得受挫。 – Aktee 2009-10-15 07:22:18

第二种选择是标准化结构，这意味着您的数据不会冗余，出错的几率较低等。我总是投票支持标准化数据，除非您遇到性能问题。无论如何，SELECT * FROM [Table]并不是好的做法。你需要输入列名。

来源

2009-10-15 06:54:47

如果出现错误等不是问题，并且如果这纯粹是表现明智的话，情况＃1会更好吗？至于Select *，谢谢，我在等待回应（相当快，实际上！），我刚刚看到select *非常糟糕。 – Aktee 2009-10-15 07:10:09

如果您使用第一种方案，则会出现空间使用量增加的问题（对于所有重复的省份，国家/地区），如果需要更改城市/国家/地区的名称，则需要将其更改为所有行它在哪里使用。

为了方便起见，我将使用第二种方案。我不认为这两种情况之间会有很大的性能差异（在第一种情况下，只触摸一个表，但从磁盘读取更多数据，在第二种情况下，您从磁盘读取的数据较少，但从多个表）。这真的取决于你在那里有什么样的数据。

编辑：为了解释我的观点之上：如果你把所有的数据在一个大表，那么你需要真正从磁盘读取所有的行，即使许多数据的读取是一样的（即城市，省，国家，大陆）。即使SQL尽可能缓存数据，在这里也不会有帮助，因为它不知道来自其他行的数据是否相同。

如果您规范化数据库并从餐馆表中读取，您将获得城市的ID。现在，如果您在多行上具有相同的ID，SQL服务器将缓存为城市读取的数据，并且不会再次打开磁盘，因此速度会提高。这将被访问新表的需求所抵消，但对于城市ID的正确索引应该不会太多。

这就是为什么我说大型数据库性能差异不容易评估，你会更好地有一个正常的数据库。

是的，如果您使用规范化的数据库（第二种方案），您可以在一个地方更改城市名称，因为城市将只有一行。这同样适用于其他国家（省，国家，大陆）。

来源

2009-10-15 06:58:45 rslite

如果我通过ID链接它们，我可以更改名称，不是？你能解释一下，或者给我一个关于“从磁盘读回更多数据”和“从磁盘读取较少但从多个表读取”的链接。我理解这一点令人困惑。数据的种类是文本。尽管我不得不承认它是一个大型数据库。 – Aktee 2009-10-15 07:07:52

如果你没有经验的数据库设计，我会建议总是去规范化的版本。在大多数情况下，这是正确的。在某些情况下，您可能想对数据库进行非规范化处理，但您应该确切地知道您为什么要这么做。

请注意，在第二种情况下，它不是多个查询。这只是一个查询，所有的表都连接在一起。例如：

SELECT * 
FROM restaurant 
    JOIN city ON city.id=restaurant.city 
    JOIN province ON province.id=city.province 
    ...

是的，它需要更长的时间来写，但它是比数据库中有不一致的数据好（保持非规范化数据库的方式更难）。你也可以使用ORM为你做这种事情。

来源

2009-10-15 07:09:19

谢谢。我想我会随着场景＃2（如果我理解规范化数据库设计的概念）。 – Aktee 2009-10-15 07:12:01

谢谢大家的意见。 “规范化数据库设计”是关键。我搜索了它，加快了阅读速度，尽管它的性能稍差，但专业人员真的很值得。

再次感谢。（这真是快btw！） http://en.wikipedia.org/wiki/Database_normalization

维基百科指出denormalized有更好的表现，但我认为我只是越来越自大，认为我可以处理一个大规模的非规范化数据库。

我会坚持风险较低的情况。如果狗屎击中风扇，我会改变硬件=）。

再次感谢你们。

来源

2009-10-15 07:21:09 Aktee

性能表（多查询vs单个大查询）的表格布局

回答

相关问题