哪个更好？或者与SP一起使用OR映射器？如果我们已经有一个带有SP的系统，那么OR映射器值得吗？

解决方案

回答

我个人发现，至少对于我定期执行的大型数据项目而言，SP往往是性能更快的明智选择。但是我知道很多人都对OR工具发誓，不会做其他任何事情。

回答

我喜欢ORM，因为我们不必重新发明轮子。话虽如此，这完全取决于应用程序需求，开发风格以及团队的需求。

已经解决了这个问题，为什么NHibernate生成的参数化SQL与存储过程一样快？

回答

在我看来，存储过程更好，因为它们可以从基础表中获得独立的安全配置。

这意味着我们可以允许特定的操作而不会允许对特定表的写入/读取。它还限制了人们发现SQL注入漏洞后可能造成的损害。

回答

我认为使用OR映射器可以提高应用程序源代码的可读性和可维护性，而使用SP可以提高应用程序的性能。

回答

存储过程放慢了手脚。或者映射器是特定于语言的，通常会增加图形速度。

存储过程意味着我们不受语言界面的限制，我们只能以向前兼容的方式为数据库添加新的界面。

我对OR Mappers的个人看法是，它们的存在凸显了流行的数据库结构中的设计缺陷。数据库开发人员应通过复杂的OR-Mappers实现人们正在尝试完成的任务，并创建有助于执行此任务的服务器端实用程序。

或者Mappers也是"泄漏抽象"综合症的史诗目标(Joel On Software：泄漏抽象)

在它很容易找到事物的地方，由于抽象层不通俗，所以无法处理。

回答

它们实际上并不是相互排斥的，尽管在我们看来，它们通常是互斥的。

使用对象关系映射的优点是可以交换数据源。不仅数据库结构，而且我们可以使用任何数据源。在大型公司中，使用出现的Web服务/面向服务的体系结构/ ESB，明智的做法是考虑将关注点分离的程度要高于存储过程中的关注点。但是，在小型公司和永不使用其他数据源的应用程序中，SP可以满足要求。最后一点，没有必要使用OR映射器来获取抽象。我以前的团队通过使用使用Spring.NET的适配器模型插入数据源而获得了巨大的成功。

回答

绝对是ORM。更灵活，更便携(通常它们倾向于内置可移植性)。如果速度较慢，则可能需要在热点中​​使用缓存或者手动调整的SQL。

通常，存储过程在可维护性方面存在几个问题。

• 与应用程序分开(现在必须在两个地方进行很多更改)
• 通常很难改变
• 难以置于版本控制之下
• 难以确保它们已更新(部署问题)
• 便携性(已经提到)

回答

在前面的问题中已对此进行了详细讨论。

将SQL保留在存储的Procs与代码中的利弊是什么

回答

@肯特·弗雷德里克(Kent Fredrick)

My personal opinion of OR Mappers is their existence highlights a design flaw in the popular structure of databases"

我认为我们是在谈论关系模型和面向对象模型之间的区别。这实际上就是我们需要ORM的原因，但是这些模型的实现是有目的的，这不是设计流程，而是事实证明它是历史。

回答

使用已确定性能瓶颈的存储过程。如果我们还没有发现瓶颈，那么过早的优化又在做什么呢？
如果我们担心对特定表的安全访问，请使用存储过程。
当我们有一个SQL向导准备好坐下来编写复杂的查询，这些查询将旧数据库中的表负载合并在一起以执行OR映射器中的困难时，请使用存储的proc。

将OR映射器用于数据库的其他80％(至少)的情况：选择和更新是如此常规，以至于仅通过存储过程进行访问就成为手动编码中毫无意义的练习，并且更新很少发生，以至于没有性能成本。使用OR映射器自动执行简单的操作。

其余的大多数OR映射器都可以与存储的proc对话。

我们不应使用存储的proc来假设它们比字符串中的sql语句快，这在MS SQL Server的后几个版本中不一定是这种情况。

我们不需要使用存储的proc来阻止SQL注入攻击，还有其他方法可以确保查询参数是强类型的，而不仅仅是字符串连接的。

我们不需要使用OR映射器来获取POCO域模型，但是它确实有帮助。

回答

如果我们已经具有作为proc公开的数据API，则需要对进行ORM的重大体系结构改革进行论证。

对于新建项目，我将评估以下几点：

• 如果团队中有专门的DBA，我会倾向于sprocs
• 如果有多个应用程序涉及同一个数据库，我倾向于进行存储
• 如果没有数据库迁移的可能性，我倾向于使用存储过程
• 如果我想在数据库中实现MVCC，则倾向于使用sprocs
• 如果我将其部署为可能具有多个后端数据库(MySql，MSSql，Oracle)的产品，那么我倾向于ORM
• 如果我的期限很紧，那么我会倾向于ORM，因为这是创建域模型并使之与数据模型保持同步(使用适当工具)的更快方法。
• 如果我以多种方式(Web应用程序，Web服务，RIA客户端)公开相同的域模型，则我倾向于ORM，因为数据模型随后隐藏在ORM幕墙后面，因此，使健壮的域模型对我。

我认为表演有点像是鲱鱼。 hibernate的性能似乎比手工编码的SQL差不多好或者更好(由于它具有缓存层)，并且很容易以任何一种方式在存储过程中编写错误的查询。

最重要的标准可能是团队的技能和长期数据库可移植性需求。

回答

SP已经在那里。能否真正做到这一点是没有意义的。我想将映射器与SP一起使用是否有意义？

回答

"我想用钉子开车。我应该用鞋跟还是玻璃瓶装的鞋跟？"

存储过程和ORM对开发人员来说都既困难又烦人(尽管不一定分别对于DBA或者架构师而言)，因为它们会产生启动成本和较高的维护成本，无法保证获得回报。

如果预计需求不会在系统的整个生命周期内发生太大变化，那么两者都将得到很好的回报，但是如果我们要构建系统以首先发现需求，这两种方式都会对我们造成阻碍。

直编码的SQL或者类似LINQ和ActiveRecord的准ORM更适合于构建到发现的项目(在企业中发生的情况比PR所希望的要多得多)。

在与语言无关的环境中，或者在需要对权限进行细粒度控制的环境中，存储过程更好。如果DBA比程序员更了解需求，那么它们也会更好。

如果我们先进行大型设计，使用大量UML，想要抽象数据库后端，并且与DBA或者程序员相比，架构师对需求的掌握更好，那么成熟的ORM会更好。

然后是选项4：全部使用。整个系统通常不仅是一个程序，而且尽管许多程序可以与同一个数据库通信，但是它们每个都可以使用适用于该程序的特定任务及其成熟度的任何方法。就是说：我们从直接编码的SQL或者LINQ开始，然后通过在我们认为它们有意义的ORM和存储过程中重构来使程序成熟。

回答

在我的工作中，我们主要从事业务应用程序合同工作。

对于此类业务，我是ORM的忠实拥护者。大约四年前(当ORM工具还不成熟时)，我们在CSLA上进行了研究，并推出了我们自己的简化的ORM工具，该工具已用于大多数应用程序中，包括一些具有100多个表的企业级系统。

我们估计这种方法(当然包括很多代码生成)在我们的项目中最多可以节省30％的时间。说真的，这太荒谬了。

性能之间的权衡很小，但是只要我们对软件开发有相当的了解，这是微不足道的。总有一些例外情况需要灵活性。

例如，如果可能的话，仍应在专用的sproc中处理非常耗费数据的批处理操作。如果我们可以直接在数据库中的存储过程中进行发送，则可能不想通过网络发送100,000条大记录。

无论新手是否使用ORM，这都是新手开发人员遇到的问题。他们只需要查看结果，如果他们有能力，他们就会得到结果。

我们在Web应用程序中看到的是，即使是ORM，通常最难解决的性能瓶颈也不再与数据库相关。相反，由于带宽，AJAX开销等原因，tey位于前端(浏览器)。如今，即使是中型数据库服务器也具有强大的功能。

当然，在更大的高需求系统上工作的其他商店在那里可能会有不同的体验。 :)

回答

关于存储过程，没什么好说的。 10年前是有必要的，但是使用存储过程的每一项好处都不再有效。关于安全性和性能，两个最常见的论点。 "通过电线发送东西"的废话也不成立，我当然可以动态创建查询以在服务器上完成所有操作。支持者不会告诉一件事是，如果我们在合并发布中使用列冲突解决方案，则它将使更新变得不可能。只有认为自己是数据库霸主的DBA才会坚持使用sproc，因为这样会使他们的工作看起来比实际要令人印象深刻。