大容量数据库的 ORM答案

【问题标题】：ORM for large volume database大容量数据库的 ORM
【发布时间】：2011-05-30 12:34:30
【问题描述】：

我正在开发面向数据的新项目，这意味着数据量非常大（每天都在增加）。所以请建议我应该使用哪种方法来实现愿望功能而没有任何障碍。

数据库是否完全规范化？
哪个ORM（linq2sql，实体框架）适合这个项目？
我应该使用存储过程、数据库函数、触发器等吗？

【问题讨论】：

标签： entity-framework sql-server-2008 linq-to-sql orm normalization

【解决方案1】：

数据库是否规范化是您需要知道并需要回答的事情！

至于 ORM：它实际上取决于数据的类型及其结构。

Linq-to-SQL 是一个非常简单的 ORM，它基本上只是将表 1:1 映射到域对象。只要您不需要其他任何东西-没关系。 Linq-to-SQL 不再被积极开发，所以这可能是一个缺点。此外，存储过程的支持有点有限。

Entity Framework（至少在 .NET 4 中）非常棒，并且是 Microsoft 当前选择的 ORM - 它正在积极开发中，有很多支持和灵活性。它提供了数据库优先、模型优先和代码优先的开发风格，它支持 POCO 对象和自跟踪实体，并且与存储过程很好地集成（您可以为每个单独的 INSERT、UPDATE、DELETE 定义存储过程实体，如果您愿意的话）。这将是我的第一选择。

NHibernate 是一个出色的企业级 ORM，已经建立并正在积极开发中——当然不是像 Linq-to-SQL 这样的“死胡同”。几年前我就用过它，虽然它很棒而且功能强大，但它也比 EF4 更难学习（没有视觉设计师，需要更多的体力劳动、体力劳动）。如果您真的需要它的全部功能并且愿意投入必要的前期学习时间，那就太好了。

至于数据库：存储过程绝对值得研究，特别是如果您需要将某些数据库处理封装到一个不错的过程中以从您的代码中调用。对于过多地使用触发器和函数，我会相当小心和防御——它们有它们的位置，但它们不应该被过度使用，因为它们确实存在一些问题（主要是性能问题和“可发现性”问题——很多开发者不要考虑可能存在的触发器，并且不会理解发生了什么）。

【讨论】：

【解决方案2】：

@Xulfee，这是一个相当广泛的问题，很大程度上取决于您项目的性质。您引用的方法会影响整个架构的许多方面。例如：

数据库是否完全规范化？
数据库规范化通常有助于解决概念模型的复杂性问题。当正确（注意我没有说“完全”）规范化时，你的模型应该是相当直接的，并且数据库的消费者（开发人员、你的 BI 团队、领域专家等）应该能够很好地了解正在处理您的数据库的业务问题。话虽如此，标准化会导致相当大的报告和分析问题。在针对大型、相当规范化的数据库编写报表查询时，您可能会通过连接大量表来引入性能问题。输入snowflake schemas。所以，对于你的问题：这取决于。你有什么报告要求？您平均需要支持多少笔交易？你的概念模型有多复杂？您能否将数据库分解为相关联的较小模型，而不是一个大模型？

哪个ORM（linq2sql，实体框架）适合这个项目？
同样，ORM 是一种工具。您必须问自己，您要完成的具体工作是什么？选择 ORM（或者甚至首先使用 ORM）是我建议您尽早做出的决定，因为它会影响从性能到开发团队凝聚力的方方面面。那里有很多很棒的选择：

上述每个框架都在抽象持久层方面做得非常出色。每个都有它的优点和缺点 - 其中大部分归结为基础设施问题：性能、配置、模式/语言兼容性、持久性模式、供应商支持。如果可以选择，我会问自己，我的开发团队最熟悉哪个框架？哪一个支持我期望的系统活动级别？我愿意与哪个供应商“投入”？我见过使用相当小的 ORM 的相当成功的系统（即 Stackoverflow 使用 Linq-To-Sql 的修改版本）以及相当大的系统因相当复杂的 ORM 而失败。

我应该使用存储过程、数据库函数、触发器等吗？
这个问题围绕着你的持久性存储以及你如何使用它（以及你想让你的 DBA 有多生气:)）。 sprocs（存储过程）的使用有助于让您的 dba 提供非常细粒度的安全性。此外，如果您使用的 orm 生成动态 sql，您可能会受益于数据库缓存使用 sprocs 生成的查询的能力。 DB 功能可以是双面刀片。它们提供了为您的模型添加功能和智能的能力，同时允许您在性能方面受到相当大的影响（即表值 UDF）。触发器有其自身的缺陷，应谨慎使用，但这种讨论可能会相当复杂。在这种情况下，我的底线是：您希望支持多少数据库中的逻辑，以及安全性和性能有多重要？您是否有合格的 dba（不仅仅是一个知道如何编写查询的开发人员，而是一个能够进行性能调优和数据建模的 dba）？你的数据库有多大？你的数据有多复杂？在确定如何管理数据时，请考虑所有这些问题以及更多问题。

总之，您提出了一些很好的问题。不要将基础设施需求与实施需求混为一谈。决定一个堆栈并使用它运行，不要在实现细节上陷入无法成功完成项目的地步。使用正确的抽象级别，您可能会发现更容易尝试新的和不同的技术，而不会危及项目的整体成功。请记住：试验和尝试新事物并没有错，只需准备优雅地失败和测试、测试、测试！

【讨论】：