Why not download the English Wikipedia? There are compressed SQL files of various sizes, and it should certainly be large enough for you
The main articles are XML, so inserting them into the db is a bit more of a problem, but you might find there are other files there that suit you. For example, the inter-page links SQL file is 2.3GB compressed. Have a look at https://en.wikipedia.org/wiki/Wikipedia:Database_download for more info.
The database contains about 300,000 employee records with 2.8 million salary entries. The export data is 167 MB, which is not huge, but heavy enough to be non-trivial for testing.
The data was generated, and as such there are inconsistencies and subtle problems. Rather than removing them, we decided to leave the contents untouched, and use these issues as data cleaning exercises.
If you want a big database of real data to play with, you could sign up for the Netflix Prize contest and get access to their data, which is pretty large (a few gigs of entries).
3rd party edit
The URL above does not contain the dataset anylonger (october 2016). The wikipedia page about the Netflix Prize reports that a law suit was settled regarding privacy concerns.
Here's a small table: create table foo (id int not null primary key auto_increment, crap char(2000));
insert into foo(crap) values ('');
-- each time you run the next line, the number of rows in foo doubles. insert into foo( crap ) select * from foo;
run it twenty more times, you have over a million rows to play with.
Yes, if he's looking for looks of relations to navigate, this is not the answer. But if by huge he means to test performance and his ability to optimize, this will do it. I did exactly this (and then updated with random values) to test an potential answer I had for another question. (And didn't answer it, because I couldn't come up with better performance than what that asker had.)
Had he asked for "complex", I'd have gien a differnt answer. To me,"huge" implies "lots of rows".
Because you don't need huge to play with tables and relations. Consider a table, by itself, with no nullable columns. How many different kinds of rows can there be? Only one, as all columns must have some value as none can be null.
Every nullable column multiples by two the number of different kinds of rows possible: a row where that column is null, an row where it isn't null.
Now consider the table, not in isolation. Consider a table that is a child table: for every child that has an FK to the parent, that, is a many-to-one, there can be 0, 1 or many children. So we multiply by three times the count we got in the previous step (no rows for zero, one for exactly one, two rows for many). For any grandparent to which the parent is a many, another three.
For many-to-many relations, we can have have no relation, a one-to-one, a one-to-many, many-to-one, or a many-to-many. So for each many-to-many we can reach in a graph from the table, we multiply the rows by nine -- or just like two one-to manys. If the many-to-many also has data, we multiply by the nullability number.
Tables that we can't reach in our graph -- those that we have no direct or indirect FK to, don't multiply the rows in our table.
By recursively multiplying the each table we can reach, we can come up with the number of rows needed to provide one of each "kind", and we need no more than those to test every possible relation in our schema. And we're nowhere near huge.
发布评论
评论（7）
您可以尝试经典的 MySQL world 数据库。
world.sql 文件可在此处下载：
http://dev.mysql.com/ doc/index-other.html
只需向下滚动到示例数据库，您就会找到它。
You could try the classic MySQL world database.
The world.sql file is available for download here:
http://dev.mysql.com/doc/index-other.html
Just scroll down to Example Databases and you will find it.
这是一个在线数据库，但您可以尝试使用 stackoverflow 数据库：
https://data.stackexchange.com/stackoverflow/query/new
您还可以在此处下载其转储：
https://archive.org/download/stackexchange
This is an online database but you can try with the stackoverflow database:
https://data.stackexchange.com/stackoverflow/query/new
You also can download its dumps here:
https://archive.org/download/stackexchange
查看 CodePlex 的 Microsoft SQL Server 社区项目和 示例
第 3 方编辑
在上面的链接顶部，您可以查看
Check out CodePlex for Microsoft SQL Server Community Projects & Samples
3rd party edit
On top of the link above you might look at
为什么不下载英文维基百科？ 有各种大小的压缩 SQL 文件，它对您来说肯定足够大
主要文章是 XML，因此将它们插入数据库有点问题，但您可能会发现那里还有其他适合您的文件。 例如，页间链接SQL文件压缩后为2.3GB。 看看https://en.wikipedia.org/wiki/Wikipedia:Database_download 了解更多信息。
奥斯卡
Why not download the English Wikipedia? There are compressed SQL files of various sizes, and it should certainly be large enough for you
The main articles are XML, so inserting them into the db is a bit more of a problem, but you might find there are other files there that suit you. For example, the inter-page links SQL file is 2.3GB compressed. Have a look at https://en.wikipedia.org/wiki/Wikipedia:Database_download for more info.
Oskar
这就是我用来学习sql的： employees-db
第 3 方编辑
根据 launchpad.net，数据库已移至 github。
This is what I am using for learning sql: employees-db
3rd party edit
According to launchpad.net the database has moved to github.
如果您想要使用真实数据的大型数据库，您可以报名参加 Netflix 有奖竞赛并获得访问权限他们的数据相当大（几GB的条目）。
第 3 方编辑
上面的 URL 不再包含数据集（2016 年 10 月）。 有关 Netflix 奖的维基百科页面报道称，有关隐私问题的诉讼已达成和解。
If you want a big database of real data to play with, you could sign up for the Netflix Prize contest and get access to their data, which is pretty large (a few gigs of entries).
3rd party edit
The URL above does not contain the dataset anylonger (october 2016). The wikipedia page about the Netflix Prize reports that a law suit was settled regarding privacy concerns.
你想要巨大的吗？
这是一个小表： create table foo (id int not null Primary key auto_increment, crap char(2000));
插入 foo(crap) 值 ('');
-- 每次运行下一行时， foo 中的行数都会加倍。
插入 foo( crap ) select * from foo;
再运行二十次，您就有超过一百万行可供使用。
是的，如果他正在寻找关系的外表来导航，这不是答案。 但如果他想测试性能和优化能力，那么这就可以了。 我正是这样做的（然后用随机值更新）来测试我对另一个问题的潜在答案。 （并且没有回答它，因为我无法想出比提问者更好的性能。）
如果他问“复杂”，我会给出不同的答案。 对我来说，“巨大”意味着“很多行”。
因为你不需要很大的东西来玩表和关系。 考虑一个表本身，没有可为空的列。 可以有多少种不同种类的行？ 只有一列，因为所有列都必须有某个值，因为没有列可以为空。
每个可为空的列都会乘以两倍的不同类型可能的行数：该列为空的行，该列不为空的行。
现在，不要孤立地考虑该表。 考虑一个作为子表的表：对于与父表具有 FK 的每个子表，即多对一，可以有 0 个、1 个或多个子表。 因此，我们将上一步中得到的计数乘以三倍（零行表示零，正好一行表示一行，多行表示两行）。 对于任何祖父母来说，父母是许多人，另外三个。
对于多对多关系，我们可以没有关系、一对一、一对多、多对一或多对多。 因此，对于我们可以从表中的图表中获得的每个多对多，我们将行乘以九——或者就像两个一对多一样。 如果多对多也有数据，我们乘以可为空数。
我们在图表中无法到达的表——那些我们没有直接或间接 FK 的表，不要将表中的行相乘。
通过递归地乘以我们可以到达的每个表，我们可以得出提供每种“种类”所需的行数，并且我们只需要这些来测试模式中的每种可能的关系。 而且我们还远没有达到巨大的程度。
You want huge?
Here's a small table: create table foo (id int not null primary key auto_increment, crap char(2000));
insert into foo(crap) values ('');
-- each time you run the next line, the number of rows in foo doubles.
insert into foo( crap ) select * from foo;
run it twenty more times, you have over a million rows to play with.
Yes, if he's looking for looks of relations to navigate, this is not the answer. But if by huge he means to test performance and his ability to optimize, this will do it. I did exactly this (and then updated with random values) to test an potential answer I had for another question. (And didn't answer it, because I couldn't come up with better performance than what that asker had.)
Had he asked for "complex", I'd have gien a differnt answer. To me,"huge" implies "lots of rows".
Because you don't need huge to play with tables and relations. Consider a table, by itself, with no nullable columns. How many different kinds of rows can there be? Only one, as all columns must have some value as none can be null.
Every nullable column multiples by two the number of different kinds of rows possible: a row where that column is null, an row where it isn't null.
Now consider the table, not in isolation. Consider a table that is a child table: for every child that has an FK to the parent, that, is a many-to-one, there can be 0, 1 or many children. So we multiply by three times the count we got in the previous step (no rows for zero, one for exactly one, two rows for many). For any grandparent to which the parent is a many, another three.
For many-to-many relations, we can have have no relation, a one-to-one, a one-to-many, many-to-one, or a many-to-many. So for each many-to-many we can reach in a graph from the table, we multiply the rows by nine -- or just like two one-to manys. If the many-to-many also has data, we multiply by the nullability number.
Tables that we can't reach in our graph -- those that we have no direct or indirect FK to, don't multiply the rows in our table.
By recursively multiplying the each table we can reach, we can come up with the number of rows needed to provide one of each "kind", and we need no more than those to test every possible relation in our schema. And we're nowhere near huge.