我的情况是，有许多不同的结构化数据集（数十万个），行数相对较少（100-10,000）和列数（10-100）。这些数据集中的每一个都只能一次访问一个。我事前并不知道确切的列。
对那些对产生上述情况的业务问题感到好奇的人。每个客户端都将输入完全自定义的数据集。然后将分析数据集并返回输出。随着新数据的投入，重新进行分析。每个客户的列几乎完全不同。分析是一些中等重度的统计数据。
似乎正确的解决方案是这样的： NoSql客户端数据。存储有关客户端在关系上下文中存储的数据类型的元数据。拉出nosql数据和分析添加更多数据。
然而，在试图给自己提供关于为什么要创建大量表格的难题时，我还没有得到满意的答案。
性能
据我所知，创建一个表相对较快，就像改变一个100-10,000行的表一样。我查了一些基准，看起来都很合理。访问数据也可以与nosql相媲美，因为我一次只查看一个表而不是一次查看。
管理混乱
我知道至少有postgres表元数据存储在表中。通过使用表元数据向我表明可以管理一堆表。在NoSql世界中，我同样会用元数据管理混乱。
表命名是另一个可能混乱的领域，但如果我查看Redis名称空间的世界，我会看到管理大量名称的合适解决方案。
我很想知道为什么这是一个可怕的想法的具体例子。表现，管理，开发时间等。
答案 0 :(得分：1)
旧版本的PostgreSQL中有很多地方需要N ^ 2次表来进行数据库转储，从转储中恢复以及使用pg_upgrade进行升级。这可能会使大约100,000张桌子难以忍受。因此，虽然系统在正常操作中运行良好，但在维护方面基本上无法管理。
大多数情况已在9.2或9.3中修复，因此如果你想这样做，你应该从版本9.3开始。
答案 1 :(得分：0)
一个风险是你有一个相当不典型的设置，没有被许多其他人测试和使用。所以你可能是第一个遇到问题的人，也是唯一一个要求修正错误的人。
如果您拥有1000名客户，我认为这不会导致问题，但您无法确定您的解决方案如何扩展到例如数百万客户。可能会出现顺序读取会导致性能下降的情况。
另一方面，如果每列都填充了数据，那么您的解决方案可以提供非常高效的数据存储。比EAV好很多因素。