我正在研究面向数据的新项目，这意味着数据量非常大（每天都在增加）。所以请建议我应该采用哪种方法来实现愿望功能，而不是任何障碍。
答案 0 :(得分：4)
数据库是否正常化是您需要了解并需要回答的问题！
至于ORM：它实际上取决于数据的类型及其结构。
Linq-to-SQL是一个非常简单的ORM，它基本上只执行表到域对象的1：1映射。只要你不需要别的东西 - 那没关系。 Linq-to-SQL不再被积极开发，因此可能是一个缺点。此外，存储过程支持有点限制。
实体框架（至少在.NET 4中）很棒，是微软当前选择的ORM - 它正在积极开发，有很多支持，很多灵活性。它提供数据库优先，模型优先和代码优先的开发风格，它支持POCO对象和自我跟踪实体，并且与存储过程很好地集成（您可以为每个单独的INSERT，UPDATE，DELETE定义存储过程）实体，如果你愿意的话）。这将是我的第一选择。
NHibernate是一个优秀的企业级ORM，已经建立并且正在积极开发 - 当然不是像Linq-to-SQL那样的“死胡同”。我几年前就用它了，虽然它功能强大，但它比EF4更难学（没有视觉设计师，需要更多的手工劳动，手动操作）。如果你真的需要所有的力量，并且你愿意投入必要的前期学习时间，那就太棒了。
至于数据库：存储过程在调查时绝对值得，特别是如果你需要将某些数据库处理封装到一个很好的proc中来调用你的代码。关于使用触发器和函数我会非常小心和防守 - 它们有它们的位置，但是它们不应该被过度使用，因为它们确实存在一些问题（主要是性能问题和“可发现性”问题 - 很多开发者不要考虑可能存在的触发因素，也不会理解正在发生的事情。
答案 1 :(得分：1)
数据库是否完全正常化？
数据库规范化通常有助于解决概念模型的复杂性问题。如果正确（注意我没说，“完全”）规范化，你的模型应该是相当直接的，数据库的消费者（开发人员，你的BI团队，领域专家等）应该能够很好地了解您的数据库正在处理的业务问题。话虽如此，规范化可能会导致相当大的报告和分析问题。在针对大型，相当规范化的数据库编写报表查询时，可能会通过加入大量表来引入性能问题。输入snowflake schemas。所以，对你的问题：这取决于。你有什么报道要求？您需要支持多少笔交易？你的概念模型有多复杂？您是否能够将数据库分解为相关的较小模型，而不是一个较大的模型？
哪个ORM（linq2sql，实体框架）适合这个项目？
同样，ORM是一种工具。你必须问自己，你想要完成的具体工作是什么？ ORM的选择（或者甚至首先使用ORM）是我建议你尽早做出的决定，因为它可以影响从性能到开发团队凝聚力的一切。那里有很多很棒的选择：
上述每个框架都可以很好地抽象您的持久层。每个都有它的专业和缺点 - 其中大部分归结为基础设施问题：性能，配置，架构/语言兼容性，持久性模式，供应商支持。有了这个选择，我会问自己哪个框架是我的开发团队最熟悉的？哪一个支持我期望的系统活动水平？我愿意“投入”哪个供应商？我已经看到使用相当小的ORM的相当成功的系统（即Stackoverflow使用Linq-To-Sql的修改版本）以及相当大的系统因相当复杂的ORM而失败。
我应该使用存储过程，数据库函数，触发器等吗？
这个问题围绕你的持久性存储以及如何使用它（以及你想让你的DBA变得多么生气:)）。使用sprocs（存储过程）有助于您的dba在非常精细的级别上提供安全性。此外，如果您使用的orm生成动态sql，您可能会受益于数据库缓存使用sprocs生成的查询的能力。 DB功能可以是双面刀片。它们提供了为模型添加功能和智能的功能，同时允许您在性能方面采取相当大的命中（即表值UDF）。触发器有其自身的缺陷，应谨慎使用，但讨论可能会涉及到相关问题。在这种情况下，我的底线是：您想要支持多少逻辑数据库，以及安全性和性能有多重要？您是否拥有合格的dba（不仅仅是知道如何编写查询的开发人员，还有能够进行性能调优和数据建模的dba）？你的数据库有多大？你的数据有多复杂？在确定如何管理数据时，请考虑所有这些问题以及更多问题。
总之，你提出了一些很好的问题。不要将基础设施需求与实施需求混淆。确定堆栈并使用它运行，不要陷入实施细节陷入无法成功完成项目的程度。通过适当的抽象级别，您可能会发现尝试新的和不同的技术更容易，而不会冒着项目整体成功的风险。请记住：尝试和尝试新事物没有任何问题，只需准备优雅地失败和测试，测试，测试！