PostgreSQL：postgreSQL 数据库中最多可以存储多少表？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/22395883/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
PostgreSQL: What is the maximum number of tables can store in postgreSQL database?
提问by Meem
Q1: What is the maximum number of tables can store in database?
Q1：数据库中最多可以存储多少张表？
Q2: What is the maximum number of tables can union in view?
Q2：view中最多可以union的表数是多少？
回答by Craig Ringer
Q1: There's no explicit limit in the docs. In practice, some operations are O(n) on number of tables; expect planning times to increase, and problems with things like autovacuum as you get to many thousands or tens of thousands of tables in a database.
Q1：文档中没有明确的限制。在实践中，一些操作在多个表上是 O(n)；预计计划时间会增加，并且在处理数据库中的数千或数万个表时会出现诸如 autovacuum 之类的问题。
Q2: It depends on the query. Generally, huge unions are a bad idea. Table inheritance will work a little better, but if you're using constraint_exclusionwill result in greatly increased planning times.
Q2：这取决于查询。一般来说，庞大的工会是个坏主意。表继承的效果会好一些，但是如果您正在使用constraint_exclusion会导致计划时间大大增加。
Both these questions suggest an underlying problem with your design. You shouldn't needmassive numbers of tables, and giant unions.
这两个问题都表明您的设计存在潜在问题。你不应该需要大量的表和巨大的工会。
Going by the comment in the other answer, you should really just be creating a few tables. You seem to want to create one table per phone number, which is nonsensical, and to create views per number on top of that. Do not do this, it's mismodelling the data and will make it harder, not easier, to work with. Indexes, where clauses, and joins will allow you to use the data more effectively when it's logically structured into a few tables. I suggest studying basic relational modelling.
根据另一个答案中的评论，您实际上应该只创建几个表。您似乎想为每个电话号码创建一个表，这是荒谬的，并在此基础上为每个号码创建视图。不要这样做，它会错误地对数据进行建模，并且会使其更难，而不是更容易使用。索引、where 子句和连接将允许您在逻辑上将数据组织到几个表中时更有效地使用数据。我建议学习基本的关系建模。
If you run into scalability issues later, you can look at partitioning, but you won't need thousands of tables for that.
如果您稍后遇到可扩展性问题，您可以查看partitioning，但您不需要为此提供数千个表。
回答by Patrick
Both are, in a practical sense, without limit.
从实际意义上讲，两者都是没有限制的。
The number of tables a database can hold is restricted by the space on your disk system. However, having a database with more than a few thousand tables is probably more an expression of an incorrect analysis of your application domain. Same goes for unions: if you have to union more than a handful of tables you probably should look at your table structure.
数据库可以容纳的表数受磁盘系统空间的限制。但是，拥有一个包含数千个表的数据库可能更多地是对您的应用程序域的错误分析的一种表现。联合也是如此：如果您必须联合多个表，您可能应该查看您的表结构。
One practical scenario where this can happen is with Postgis: having many tables with similar attributes that could be joined in a single view (this is a flaw in the design of Postgis IMHO), but that would typically be handled at the application side (e.g. a GIS).
一种可能发生这种情况的实际场景是 Postgis：有许多具有相似属性的表可以连接到一个视图中（这是 Postgis 恕我直言的设计缺陷），但这通常会在应用程序端处理（例如地理信息系统）。
Can you explain your scenario where you would need a very large number of tables that need to be queried in one sweep?
您能解释一下您需要一次性查询大量表的场景吗？
