我们正在创建一个数据库，我们存储大量记录。我们估计在一个表中有数百万（数十亿年后）的记录，我们总是插入并且很少更新或删除任何记录。它是一种我们每天插入历史记录的档案系统。我们会生成不同的排序对用户请求的这一历史性的记录报告，以便我们已经有些担忧，并要求从你的人的技术输入：大量数据库
什么是管理这种表和数据库的最好方法？
如果您打算存储数十亿条记录，那么您将需要大量磁盘空间，我建议运行SQL 2008 R2的64位操作系统以及尽可能多的RAM和HD空间。根据你需要的性能，我会试图研究SSD。
对于我们未来可能会看到的非常大的表格有什么影响？
如果您拥有合适的硬件，并且具有正确索引的表格并正确标准化，那么您应该注意到的唯一情况是报告将开始运行较慢。随着索引文件变大，插入可能会稍微减慢，您只需要留意它。
对一张表格或表格大小的记录数量是否有限制？
在上面描述的正确设置，没有。它仅受磁盘空间限制。
我们如何设想从不同来源插入批量记录（大部分来自Excel工作表）？
我遇到了运行大量SQL查询的问题，但我从来没有尝试从非常大的平面文件导入。
索引大数据表的最佳方法是什么？
根据需要索引为少量字段并仅将它们保留在数字字段中。
我们应该在这个项目中使用哪种最好的ORM（对象关系映射）？
对不起，不建议这里。
“几年”中的数十亿行不是特别大的卷。 SQL Server应该完全适应它 - 假设你的设计和实现是合适的。表格的大小没有特别的限制。坚持坚实的设计原则：对表格进行规范化处理，仔细选择键和数据类型，并有适当的分区和索引策略。
你最后的声明总结了它。没有ORM可以很好地处理这些数据和报告查询：使用SQL专家为您提供帮助。你先在这里听到了。
否则
一些这些数据是基于我们在30个月内通过我们的一个系统获得的约100亿行数据的经验，峰值为40k行+每秒。
也为高容量系统显示方式：10 lessons from 35K tps
总结：做正确或者根本没有...
当然，如果你打算有一个高容量的系统，聘请专家来设计它。 – HLGEM 2011-06-01 18:04:12
在一个职位有很多的问题 - 而且并非所有与“大容量数据库” - 你会很好地将其中的一部分分离出来并提供更多信息。 – 2011-06-01 06:24:14
因[dba.se]（http://dba.stackexchange.com/q/3074/630）过于宽泛，已关闭 – gbn 2011-06-01 06:58:56
您需要的是一位数据库专家，最好拥有至少十年以上的高级经验体积系统。 – HLGEM 2011-06-01 18:05:28