基本上我有一个来自异地服务器的xml提要。
xml feed有一个参数？value = n现在N只能在1到30之间
我选择的任何值，XML文件总会返回4000行。我的脚本每天会为每个值调用此xml文件30次。那就是120000行。我将对这些行进行非常复杂的查询。但最重要的是我将始终按值进行过滤，以便SELECT * WHERE value = 'N'等等。总是会使用它。
现在最好有一个表存储所有120k行？或30个表是否存储了4k行？
编辑：有问题的SQL数据库将是MySQL
编辑：为了让它更清晰，数据将每天更新，因此旧表将被覆盖，我不想要任何存档解决方案，只是存储数据的最佳方式，以获得尽可能少的性能瓶颈尽可能地，输出的数据库结果将被缓存并每天更新。 编辑：我想我对自己的好处太过模糊了:(基本上，Feed是排行榜，每个值都是不同的排行榜位置只有在排行榜位置发生变化且总是只有120k行时，才会更新这些值。不多也不少。
让我们说：
当前的排行榜和Feed返回的下一次更新：
只有第2行和第3行会发生变化。无论如何，这是我的计划:)）
另一个编辑＆gt;。＆lt;： 这些行最多只包含12列，每行少于1kb。而且更新只会在一天发生，因为源来自的服务器很慢，我的服务器需要80分钟才能从中获取所有Feed值。
答案 0 :(得分：3)
在存储方面，120k行表和30个4k表之间几乎没有区别。
在维护方面，我总是选择一张桌子。它使您的代码和SQL更容易使用，并且由于您已经使用WHERE子句，我认为没有任何理由拆分表。
答案 1 :(得分：0)
只要您正确索引，一个表就会更快。你肯定需要一个关于你的值的索引（你应该称之为'value'是sql中的保留字）。
在您考虑的音量上，存储不应成为问题。如果您长期这样做，您可能需要调查旧数据的归档解决方案。
答案 2 :(得分：0)
单个表是我的首选。
我知道它不会包含单个导入的数据，而是包含WHERE子句的数据。
查询最初可能不会像您希望的那样快速恢复，您可以通过正确的索引解决问题。
更重要的是，如果由于某种原因你选择每天45次或每天90次或每5分钟一次（12 * 24 =每天288次），你会怎么做？创建288个表并更改与这些表相关的所有查询将是一项巨大的工作。
答案 3 :(得分：0)
你想要一张桌子。否则，您必须编写30个不同的查询，或构建动态查询解决方案（yuck）。
行有多宽？更重要的是，8k SQL页面上有多少行？ （您可以根据它来估计您的磁盘I / O.）您的硬件需要多长时间才能读取这么多数据？或者它是否都适合内存，这样你就不会经常碰到磁盘了？我的观点是，你确实遇到了性能问题吗？
在表上放置一个复合聚簇索引，使得“n”值是第一列，这将优化这些读取（但前提是在WHERE子句中始终具有“n”值）。或者，如果“n”始终介于固定值1和30之间，并且您使用的是SQL 2005及更高版本，则可以实现表分区，这将为您提供相同的性能提升，并且可能会提供更多的灵活性。加载或卸载数据。
答案 4 :(得分：0)
正如所有其他人所说，请选择一张桌子。由于这一个表，数据库端不存在任何瓶颈性能，除非您的数据库已经设置不当，在这种情况下，这将揭示情况，而不是导致它。如果对涉及流中所有组件的详细信息（从用户启动请求到返回结果的时间）进行性能分析，您将看到在您的示例中数据库组件不会添加任何重要的性能损失。正如其他答案所指出的那样，您必须根据您的具体查询定义正确的索引。
答案 5 :(得分：0)
正如Oded所说，120K行没有真正的缩放/性能问题，所以我也会选择独特的表（为了简单起见）。
如果您将来需要扩展很多，请记住this article on "why SQL databases don't scale"。除此之外，文章解释了为什么“分区”（或“分片”）对SQL数据库不利：
Sharding会将您的数据划分为一些 特定于应用程序的边界。 例如，您可以存储用户 其名称以A-M开头 数据库和另一个N-Z。或者使用 用户id的模数由数字表示 数据库。
这需要深入整合 申请和精心策划 分区方案相对于 数据库架构和种类 您想要做的查询。总结：大 屁股疼痛。
因此，分片是一种形式 水平缩放，它失败了第2点： 它对业务不透明 应用程序的逻辑。
分片的更深层次问题是 SQL数据库是关系型的 数据库，以及大部分的价值 关系数据库是它存储的 关系。一旦你拆分记录 在多个服务器上，你是 服务于许多这些关系; 他们现在必须重建 客户方。 Sharding杀死最多 关系数据库的价值。
即使这最初被称为更多数据库之间的分区，也可以将相同的概念应用于您的案例，在这种情况下，您尝试实现某种“内部”分区。
结论，实际缩放的答案是NoSQL。再次，不是120K行：）