我们正在创建一个存储大量记录的数据库。我们在一个表中估计数百万（几年后数十亿）的记录，我们总是INSERT并且很少更新或删除任何记录。它是一种存档系统，我们每天都会插入历史记录。我们将根据用户请求生成关于此历史记录的不同类型的报告，因此我们有一些顾虑并需要您的技术输入：
答案 0 :(得分：4)
你最后的陈述总结了它。没有任何ORM可以很好地处理这些数据和报告查询：聘请SQL专家为您完成。你先在这里听到了。
否则
其中一些是基于我们在30个月内通过我们的系统中大约100亿行的经验，峰值为每秒40k行+。
对于高容量系统也是如此：10 lessons from 35K tps
总结：做得好还是不做......
答案 1 :(得分：0)
管理此类表和数据库的最佳方法是什么？
如果您计划存储数十亿条记录，那么您将需要大量的磁盘空间，我建议运行SQL 2008 R2的64位操作系统以及尽可能多的RAM和HD空间。根据您需要的性能，我很想看看SSD。
对于非常大的桌子，我们将来会看到什么影响？
如果您拥有正确的硬件，使用正确索引的表并正确规范化，您应该注意的唯一事情是报告将开始变慢。
表示，随着索引文件越来越大，插入内容可能会略微减慢，您只需要注意它。一个表格或表格大小的记录数量有限制吗？
在我上面描述的正确设置中，没有。它仅受磁盘空间的限制。
我们如何从不同来源（主要来自Excel工作表）插入批量记录？
我遇到运行大量SQL查询的问题，但我从未尝试从非常大的平面文件导入。
索引大型数据表的最佳方法是什么？
根据需要为少数字段编制索引，并将它们仅保留在数字字段中。
我们应该在这个项目中使用哪个最好的ORM（对象关系映射）？
抱歉，不能在这里提出建议。
答案 2 :(得分：0)
“几年”中的数十亿行并不是特别大的数量。 SQL Server应该很好地应对它 - 假设您的设计和实现是合适的。表的大小没有特别限制。坚持坚实的设计原则：规范化表格，仔细选择密钥和数据类型，并采用合适的分区和索引策略。