5

我正在研究面向数据的新项目,这意味着数据量非常大(日益增加)。所以,好心的建议我应该采用哪种类型的方法来实现欲望功能而没有任何障碍。用于大容量数据库的ORM

  • 数据库是否完全标准化?
  • 哪个ORM(linq2sql,实体框架)适合这个项目?
  • 我应该使用存储过程,数据库函数,触发器等吗?

回答

4

无论数据库是规范化的东西需要知道和需要回答!

至于ORM:它确实取决于数据的类型及其结构。

Linq-to-SQL是一个非常简单的ORM,它基本上只执行表与域对象的1:1映射。只要你不需要别的东西 - 没关系。 Linq-to-SQL不再被积极开发,所以这可能是一个缺点。此外,存储的proc支持有点有限。

实体框架(至少在.NET 4中)非常棒,它是微软当前选择的ORM--它正在积极开发中,具有很多的支持和很大的灵活性。它提供了数据库优先,模型优先和代码优先的开发风格,它支持POCO对象和自我跟踪实体,并且与存储过程很好地集成(你可以为每一个单独的INSERT,UPDATE,DELETE定义一个存储过程实体,如果你想这样做的话)。这将是我的第一选择。

NHibernate是一个伟大的企业级ORM,已经建立并积极开发 - 当然不是像Linq-to-SQL这样的“死胡同”。我几年前就已经使用过,虽然功能强大,但与EF4相比,它的学习难度更大(没有可视化设计师,需要更多的手工劳动,手动工作)。如果你真的需要全部的力量,并且愿意投入必要的前期学习时间,那将是非常棒的。

至于数据库:存储过程是绝对值得研究,特别是如果你需要封装某些数据库处理成一个不错的过程来调用你的代码。我会对使用触发器和函数太过谨慎和防守 - 它们有自己的位置,但不应该被过度使用,因为它们确实带有一些问题(主要是性能问题和“可发现性”问题 - 很多开发人员不要考虑可能存在的触发器,也不会理解正在发生的事情)。

1

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

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

哪个ORM(LINQ2SQL,实体框架),是适合这个项目?
再次,一个ORM是一个工具。你必须问问你自己想要完成的具体工作是什么?选择一个ORM(或者甚至在首先使用ORM)是一个决定,我会建议你尽早做出决定,因为它会影响从性能到开发团队凝聚力的所有内容。有很多伟大的选择在那里:

上述每个框架做抽象你的持久层的出色的工作。每种方法都有专业和缺陷 - 其中大部分涉及到基础架构问题:性能,配置,模式/语言兼容性,持久性模式,供应商支持。考虑到选择,我会问自己哪个框架是我的开发团队最熟悉的?哪一个支持我期望的系统活动水平?我愿意“投入”哪个供应商?我看到相当成功的系统使用相当小的ORM(即,Stackoverflow使用Linq-To-Sql的修改版本)以及相当大的系统失败且具有相当复杂的ORM。

我应该使用存储过程,DB函数,触发器等?
在你的持久性存储,以及如何使用它这个问题中心(以及你想怎么生气,让您的DBA :))。 sprocs(存储过程)的使用有助于您的dba以非常细致的级别提供安全性。另外,如果您正在使用的orm生成动态sql,那么您可能会从数据库缓存使用sprocs生成的查询中受益。数据库功能可以是双面刀片。它们提供了向模型添加功能和智能的能力,同时还可以让您获得相当大的性能优势(即表值UDF)。触发器有其自身的缺陷,应谨慎使用,但讨论可能会相当复杂。在这种情况下,我的底线是:数据库中有多少逻辑要支持,安全性和性能有多重要?你是否有合格的dba(不仅仅是知道如何编写查询的开发人员,而且是能够进行性能调整和数据建模的dba)?你的数据库有多大?你的数据有多复杂?在确定如何管理数据时,请考虑所有这些问题以及更多问题。

总之,你问一些很好的问题。不要将基础设施需求与实施需求混为一谈。决定一个堆栈并运行它,不要陷入执行细节,直到无法成功完成项目。通过适当的抽象级别,您可能会发现,尝试新的不同的技术并不会冒险完成项目的整体成功。请记住:没有什么错试验和尝试新事物,只是要准备失败优雅测试,测试,再测试!