我有几个包含简单数据的数据库需要导入到新的格式模式中。我提出了一个灵活的架构，但它依赖于旧DB的关键数据存储在一个表中。此表只有一个主键，一个外键（两个int），一个日期时间和一个十进制字段，但是添加两个旧DB的行数表示该新表的总行数约为200,000,000行。
如何处理这些数据？数据可以追溯到大约10年，并且需要提供。幸运的是，在将来进行查询时，我们不需要提取1％的内容，但确实需要访问它们。
我有基于年度多个表，供应商（源数据）等的想法 - 甚至每年都有一个数据库，最近2年在一个数据库中（也包含存储的数据库）处理这一切的过程。）
非常，深刻，非常感谢的任何和所有帮助，想法和建议，
太
答案 0 :(得分：1)
最重要的是。考虑分析您的查询并测量您的实际瓶颈所在（尝试识别missing indexes），您可能会发现可以将所有内容存储在一个表中，或者购买一些额外的硬盘就足以获得足够的性能
现在，对于建议，你考虑过分区吗？您可以为每个时间范围创建分区，或者一个分区通常访问1％，另一个分区使用99％的数据。
这大致相当于按年份或供应商或诸如此类别手动拆分表，但由服务器内部处理。
另一方面，实际将表格拆分为“当前”和“历史”可能更有意义。
另一种可能的大小改进是使用int（比如epoch）而不是datetime，并提供从datetime转换为int的函数，因此具有类似
的查询SELECT * FROM megaTable WHERE datetime > dateTimeToEpoch('2010-01-23')
如果您需要执行复杂的日期时间查询，这样可以节省大小成本。 Although on cubes there is the standard technique of storing, instead of an epoch, an int in YYYYMMDD format.
答案 1 :(得分：1)
将这些数据存储在一个表中有什么问题？像Microsoft SQL 2005这样的企业级SQL服务器可以毫不费力地处理它。
顺便说一句，不要每年做表，每个供应商的表或其他类似的东西。如果您必须存储类似的项目集，则只需要一个和一个表。设置多个表来存储相同类型的东西会导致问题，例如：
查询非常难以编写，如果必须从多个表中查询，性能会降低。
数据库设计将很难理解（特别是因为在不同的地方存储相同类型的项目并不自然。）
您将无法轻松修改数据库（可能在您的情况下不是问题），因为您不必更改一个表，而是必须更改每个表。
需要自动完成一系列任务。让我们看看你每年都有一张桌子。如果在2011-01-01 00：00：00.001插入新记录，是否会创建新表？如果必须创建新表，是否会检查每个插入？它会如何影响性能？你能轻易测试一下吗？
如果“最近”和“旧”数据之间存在真实，可见的分离（例如，您必须每天使用上个月保存的数据，并且您必须保持较旧的一切，但不要使用它），您可以构建一个带有两个SQL服务器的系统（安装在不同的机器上）。第一个高可用性服务器将用于处理最新数据。第二种，较少可用和优化的写作，将存储其他一切。然后，按计划，程序会将旧数据从第一个数据移动到第二个数据。
答案 2 :(得分：1)
如此小的元组大小（2个整数，1个日期时间，1个小数）我认为你可以很好地拥有一个包含所有结果的表。 SQL Server 2005不限制表中的行数。
如果你走这条路并遇到性能问题，那么现在是时候看看替代品了。在那之前，我会继续前进。
编辑：假设您使用的是DECIMAL（9）或更小，您的总元组大小为21个字节，这意味着您可以将整个表存储在少于4 GB的内存中。如果你有一个不错的服务器（8 GB以上的内存）并且这是主内存用户，那么表和二级索引可以存储在内存中。这应该确保在填充缓存之前较慢的预热时间之后进行超快速查询。