orm模型的含义（LINQ和存储过程有什么区别）

本文目录

• LINQ和存储过程有什么区别
• 为什么我说ORM是一种反模式
• 资料模型的含义是什么为什么要建立资料模型
• 请简述MyBatis和Hibernate的区别

LINQ和存储过程有什么区别

你说关公和秦琼那个厉害?张飞和徐达那个厉害?
------------------------------------------------------------
恭喜你!总算知道我要说什么了!不是一个时期的东西呀!
LINQ TO SQL 只是 一种理念.一种ORM模型, 在CLR运行时进行转化,可以转化为IL, LINQ TO SQL 就可以转化为SQL报文!然后发送给数据库! 这种技术比较新! 07年开始盛行!
cs 代码写 CRUD也是 借用ADO.NET等技术. LINQ TO SQL 底层也是这个!只是高层封装了一些理念. ADO.NET本身也不错!可以直接调用指令, linq to sql 调用原始sql 指令比较麻烦. 有类型转化和安全的限制,所以linq to sql 技术是有弊病的!
cs 借助 ado.net写代码有历史沉积!所以资源多!稳定性也高!
存储过程是数据库提供的技术,跟CLR一点关系也没有. 这个历史更久了! 比net都早!
总结一下吧:
Linq to sql本质实现也是ADO.NET,是一种ORM技术!是一种理念.当然 linq to xml 等是借助CLR集合操作等技术实现. Linq to sql 运行时转化 成SQL报文 .然后发送.
代码中 的CRUD就是 ADO.NET等系列技术实现,代码发送SQL报文
存储过程的实现SQL封存在数据库,所以向数据库发送的只是调用指令. 速度体现在SQL计划编译,
指令网络传输.
到底那个优秀要看你的需要了! 比如你的数据库机器维护成本高!你不可能总让外围指令传入吧!
至少中间有个缓冲层吧! 比如报盘软件,1秒读取数据库 500万次! 靠存储过程提速那就喝西北风去吧!
存储过程如果有bug 那就是数据库灾难,你可知道sqlserver时间类型转化出错后,日志可是不能恢复的.
所以写程序找好层次也是很重要的事情!
以上都是本人所写,没有COPY任何网站的数据. 原稿原创!

为什么我说ORM是一种反模式

上周我在在上讨论了ORM，在那以后有人希望我澄清我的意思。事实上，我曾经写文章讨论过ORM，?但那是在一场关于SQL的大讨论的上下文中，我不应该把这将两件事情混为一谈。 因此，在本文中我将关注ORM本身。同时，我尽力保持简略，因为从我的SQL文章中显而易见



上周我在在上讨论了ORM，在那以后有人希望我澄清我的意思。事实上，我曾经写文章讨论过ORM，?但那是在一场关于SQL的大讨论的上下文中，我不应该把这将两件事情混为一谈。 因此，在本文中我将关注ORM本身。同时，我尽力保持简略，因为从我的SQL文章中显而易见的是：人们倾向于一旦读到让他们发怒的内容就会离开（同时留下一句留言，而不论他们所关注的东西是否在后面会讨论到）。
什么是反模式？
我很高兴地发现Wikipedia有一个相当全面的关于反模式的列表，包括来自编程界及其之外的内容。我之所以称ORM为反模式的原因是因为，反模式的作者定义了用来区分反模式和普通的坏习惯的两个条件，而ORM完全符合这些条件:
它开始的时候看起来很有用，但是从长期来看，坏处要大过好处
存在已验证并且可重复的替代方案
由于第一个因素导致了ORM令人抓狂（对我来说）的流行性：它第一眼看上去像是个好主意，但是当问题更加明显的时候，已经很难离开了。
这对ORM来说是什么意思？
我想说的主要问题在于?ActiveRecord，它由于 Ruby on Rails 而著名， 从那以后已经移植到了许多其他语言。然而，这些问题同样存在于其他的ORM层，比如Java的Hibernate和PHP的Doctrine。
ORM的优点
简单：一些ORM层告诉你它们“消除了对SQL的要求”。我至今仍然看到这种承诺在传播。其他一些会更加现实地声称它们可以减少手写SQL的需要，但是仍然允许你在需要的时候使用它。对于简单的模型以及项目的早期，这确实是一个优点：使用ORM，无疑你能够更快地开始启动。然而，你将会走向错误的方向。
代码生成：使用ORM从模型中消除用户层面的代码，这一做法开启了通向代码生成的大门。通过对schema的简单描述，“脚手架”模式可以为你的所有表生成一个可工作的界面。更加具有魔力的是，你可以修改你的schema描述，然后重新生成代码，从而消除了CRUD。同样，这在开始的时候确实是可行的。
性能“足够好”：我没有看到任何ORM层声称在性能上更加优越。很明显，为了代码的敏捷性需要付出性能的代码。如果哪里变慢了，你总是可以用更加有效的手写SQL覆盖你的ORM方法。不是吗？
ORM的问题
1. 不充分的抽象
ORM最明显的问题是它并不能完全从实现细节中抽象出来。所有主流ORM的文档中到处都引用了SQL的概念。其中一些介绍的时候并不会表明其在SQL中的等价物，而其他一些则将库看作用来生成SQL的过程函数。
抽象的要点在于它应该使问题得以简化。对SQL进行抽象，同时又要求你懂得SQL，这使得你需要学习的东西成倍增加了：首先，你必须理解你正在试图执行的SQL是什么，然后你还要学习ORM的API，来让它为你编写这些SQL。在Hibernate中，为了完成复杂的SQL你甚至需要学第三种语言：HQL，它几乎就是SQL（但又不完全是），其在幕后被翻译成SQL。
ORM的支持者会辩解说并非每个项目都是如此，并非每个人都需要复杂的join，并且ORM是一个"80/20"解决方案，其中80%的用户只需要SQL中20%的功能，ORM可以处理这些问题。我能说的是，我15年来编写web应用的数据库后端的经历表明，事实并非如此。只有在项目刚开始的时候你不需要join和本地join。在那之后，你就要优化和巩固你的查询。即使80%的用户只用到SQL中30%的功能，可是100%的用户都需要打破ORM的抽象才能够完成工作。
2. 不正确的抽象
如果你的项目确实不需要任何关系数据功能，那么ORM可以非常完美地为你工作。但是接下来你又遇到另外一个问题：你用错了了数据存储。关系存储的额外付出是非常高的；这就是为什么NoSQL数据要快得多的重要原因之一。然而，如果你的数据是关系型的，那么额外的付出就是值得的：你的数据库不仅存储数据，它还表达了你的数据，并且可以基于关系概念回答关于它的问题，这比你用过程代码能够做到的要快速得多。
但是，如果你的数据不是关系型的，那么你就是在不适当的场合使用SQL，这为你增加了巨大且不必要的负担；为了让问题更加严重，你在其上又增加了一重额外的抽象。
另一方面，如果你的数据是关系型的，那么你的对象映射最终会失败。SQL是关于关系代数的：SQL的输出不是对象，而是对于某个问题的解答。如果你的对象“是一个”X的实例，并且“拥有一些”Y，且每个Y“属于”Z，那么对象在内存中正确的表达形式是什么？ 它应该是X的属性，或者全部包含在Y中，或者/并且全部包含在Z中？如果你只得到X的属性，那么何时你运行查询来获得Y呢？而且，你是想要其中一个还是全部？现实中，答案是依赖于条件的：这就是为什么我说SQL是对于问题的回答。对象在内存中的表达形式取决于你的意图，然而面向对象设计没有依赖于上下文的表达这样的功能。关系不是对象；对象也不是关系。
3. 多个查询导致失败
这自然的引出了ORM的另一个问题：效率低下。当你获取一个时，你需要哪些属性？ORM并不知道，所以它总是取得全部（或者它要求你告诉它，但是这又打破了抽象）。开始的时候这不成问题，但是当你一次取出上千条纪录的时候，如果你只需要3个属性却不得不取出全部30列，这时就产生了严重的性能问题。许多ORM层非常不善于推断join，从而不得不使用分离的查询来获取关联数据。如前所述，许多ORM层明确声明效率将会有所牺牲，其中一些提供了某些机制来调整引起问题的查询。我从过去的经历中发现的问题表明，很少有只需要调整单个“银弹”查询的情况：应用的数据库后端之所以死掉不是因为其中某一条查询，而是众多的查询引起的。ORM缺少上下文敏感的性质意味着它无法巩固查询，相反必须借助cache或其他机制来进行一定程度的补偿。
那么替代方案是什么?
希望到这里我已经澄清ORM在设计上的一些缺陷。但是要作为一个反模式，还需要存在替代的解决办法。事实上有两个取代方法：
1. 使用对象
如果你的数据是对象，那么停止使用关系数据库。编程界当前正在出现键-值对存储的浪潮，它允许你以闪电般的速度访问优雅的、自我包含的海量数据。没有法律规定编写Web应用的第一步必须安装MySQL。对于对象的每一种表达方式都使用关系数据库是一种过度使用，这也是近几年SQL的名称不太好的原因之一。事实上，问题在于偷懒的设计。
2. 在模型中使用SQL
编程中作任何事情都只有一种正确的方式，这是一种危险的说法。然而根据我的实践，在面向对象的代码中表达关系模型的最佳方法仍然是模型层：将你的所有数据表示封装在一个单独的区域是一个好注意。然而，记住模型层的工作簿在于表达对象，而在于回答问题。提供一个可以回答你的应用程序所包含的问题的API，尽量保持简洁高效。有时候，这些回答显得格格不入，以致于看上去是“错误的”，甚至对于资深的OO开发者也是如此。但是，你可以根据经验来更好地找到其中的普遍性，从而允许你将多个查询方法重构为单个。
类似的，有时候输出会是单个对象X，它很容易表达。 但是也有时候输出是聚合的对象表格，或者单个整数值。你要忍住将这些内容用过多抽象来包装的诱惑，用对象自身的术语来描述。首要的是，不要相信OO能够表达任何对象和所有对象。OO本身是一种优美和灵活的抽象，但关系数据在其范围之外，把它不能表达的东西伪装成对象是ORM的核心与真正的问题。
总结
ORM最初比编写基于SQL的模型代码更快，也更容易理解
它在任何项目早期都是足够有效的
不幸的是，这些优点在项目复杂性提升的时候就消失了：抽象被打破，开发者被迫使用并理解SQL
完全是非正式的声明，我认为ORM对抽象的破坏不是仅仅涉及20%的项目，而是几乎100%。
对象并不足以充分表达关系查询的结果。
关系查询映射到对象的不充分性导致了ORM后端应用的效率低下，这些问题普遍分布在应用的各处，并且除了完全放弃ORM之外，没有简单的解决办法。
不要对任何问题都使用关系存储与ORM，而是更加仔细地思考你的设计
如果你的数据天生就是对象，那么请使用对象存储（"NoSQL"）。它们要比关系数据库快得多。
如果你的数据天生就是关系型的，那么关系数据库带来的开销是值得的。
把你的关系查询封装在模型层中，设计你的API从而为应用提供数据访问支持；拒绝过分泛化的诱惑。
面向对象无法以有效的形式表达关系数据；这是面向对象设计的一个基本限制，ORM无法修复它。

资料模型的含义是什么为什么要建立资料模型

资料模型的含义是什么？为什么要建立资料模型
模型是对现实世界的抽象。在资料库技术中，表示实体型别及实体型别间联络的模型称为“资料模型”。 资料模型是资料库管理的教学形式框架，是用来描述一组资料的概念和定义，包括三个方面： 1、概念资料模型（Conceptual Data Model）：这是面向数...
金融为什么要建立数学模型
否则呢？分析资料不用数学模型去拟合，难道凭空猜吗？
建立模型物件时传入的资料为什么后面还要重写
那叫物件关系资料库对映。Hibernate的原理..核心部分. 物件关系对映（ORM）提供了概念性的、易于理解的模型化资料的方法。ORM方法论基于三个核心原则： 简单：以最基本的形式建模资料。 传达性：资料库结构被任何人都能理解的语言文件化。 精确...
资料库的开发过程中主要有哪三种资料模型
一般一种资料库对应一种资料模型，所以正确的提法是：资料库中资料模型主要有哪些模型吧？
我猜你是接下来要考《资料库概论》吧，呵呵！以我的经验来看，资料库考的话，这类问题顶多出个选择题或者填空题，就算考“这些模型的特点是什么？”也应该不会是简答题，考你些干条条，毕竟“资料库”不是‘大学思想政治课’。

这应该是《资料库概论（第四版）》中第一章绪论里面的知识，绪论算是基础篇里的概论，应该说都是些前导概念吧，这些概念的实际应用是在后续章节中展开的，所以这些了解了解就可以了。

资料模型主要有哪些模型？

答：模型：对现实世界中某个物件特征的模拟和抽象。

【了解】

两大类资料模型：

资料模型分为2类（分属2个不同的层次，在开发和使用资料库中使用不同的模型）

①概念模型，也称资讯模型，它是按使用者的观点来对资料和资讯建模，用于资料库设计。

②逻辑模型和物理模型，

逻辑模型主要包括：网状模型、层次模型、关系模型、面向物件模型等，按计算机系统的观点对资料建模，用于DBMS实现。

物理模型，是对资料最底层的抽象，描述资料在系统内部的表示方式和存取方法，在磁碟或磁带上的储存方式和存取方法。

概念模型：资讯世界中的基本概念。

用途：资料库设计人员和使用者之间进行交流的语言。所以，这个了解就可以了；但要考E-R图！

最常用的资料模型：非关系模型，有层次模型和网状模型；关系模型；面向物件模型、物件关系模型。

——————————————————————————————————————————

【掌握】

层次模型：用“树形结构”来表示各类实体以及实体间的联络。

特点：结点的双亲是唯一的；只能直接处理一对多的实体联络；每个记录型别可以定义一个排序栏位，也称为：码栏位；任何记录值只有按其路径检视时，才能显示它的全部意义；没有一个子女记录值能够脱离双亲记录值而独立存在。

网状模型：满足下面2个条件的基本层次联络的 *** ：①允许一个以上的结点无双亲②一个结点可以有多于一个的双亲。

特点：优点，能够更为直接地描述现实世界，如一个结点可以有多个双亲；具有良好的效能，存取效率较高。

缺点，结构比较复杂，而且随着应用环境的扩大，资料库的结构就变得越来越复杂，不利于终端使用者掌握；DDL、DML语言复杂，使用者不容易使用。

关系模型：在“使用者观点”下，关系模型中资料的逻辑结构是一张二维表，它由行和列组成。

特点：优点，建立在严格的资料概念的基础上；概念单一（实体和各类联络都用关系来表示；对资料的检索结果也是关系）；关系模型的存取路径对使用者透明（具有更高的资料独立性，更好的安全保密性；简化了程式设计师的工作和资料库开发建立的工作）。

缺点，存取路径对使用者透明导致查询效率往往不如非关系资料库；为提高效能，必须对使用者的查询请求进行优化，增加了开发DBMS的难度。
为什么需要使用者角色模型
最近，我自己一直在做一些活动页面和移动端游戏，我渐渐意识到角色模型的重要性。角色模型，是设计产品时的指路灯，是产品经理和互动设计师的设计参考。 　　建立角色模型，是在剥皮(就像剥洋葱一样，虽然会流泪，但洋葱的味道还是不错的)吗?是的，我们需要剥出使用者的灵魂，然后再为这些灵魂赋予血肉，穿上外衣(人口统计学特征)。这样的话，我们会感觉使用者就在我们身边，生动形象，印象深刻。仅仅剥皮是不够的，我们还需要总结归类，了解使用者的目标、观点和行为，发现使用者间的差异和共同点。 　　按使用者研究型别和分析方法的不同，建立角色模型有三种方法：定性人物角色、经定量验证的定性人物角色和定量人物角色。结合阿里巴巴中文站交易线使用者角色模型专案，对以下建立方法进行分析： 　　研究方法也有很多，常用的方法有：调查问卷、使用者访谈、现场观察、可用性测试、资料分析、网站流量/日志分析。交易线专案中，访谈、调查问卷和资料分析有利于发现使用者的目标和观点;现场观察、网站流量/日志分析有利于了解使用者的行为。 　　在建立角色模型的过程中，经常会遇到以下几个问题： 　　1. 怎么利用资料进行细分?怎么看资料的规律? 　　从资料中找出纬度差异，并找出造成这种差异的所有相关因素。 　　2. 怎么设计调查问卷?有何纬度? 　　按交易整个流程订单-管理-支付-物流和产品维度(考虑使用者实际操作流程)。 　　3. 怎么写深访提纲? 　　了解使用者的哪些资讯，参考使用者角色划分维度问卷。 　　4. 怎么进行CRM分析?见相关专题 　　5. 怎么进行交叉表分析?见相关专题 　　6. 怎么细分使用者? 　　一般来说，按使用者目标细分、按使用周期来细分、用行为和观点的组合来细分。在交易线人物角色专案中，细分角色是按照驱动使用者目标、行为和观点产生差异的关键因素， 如：货物来源不同，购物动机不同。 　　7. 怎么初步检验细分纬度? 　　细分群体可以解释已知的关键差异，如：买房目标(二手房使用者和新房使用者)不同，可以解释关键字搜寻使用存在的差异);细分群体应该在决定功能设计、互动设计和草图方面起决定性作用。 　　6. 定量验证都有哪些方法? 　　资料交叉Tab分析(CRM分析、定量问卷、网站流量/日志分析)、统计式的分析。 　　7. 人物角色需要哪些特征? 　　参考角色模型引数，人物角色是由目标、行为和观点来驱动的，而非一些简单的人口统计特征。 　　8. 人物角色模型的使用? 　　开发新功能及功能改进(了解使用者需求)，互动设计细节(了解使用者习惯)。 　　建立角色模型时，需要学习的相关专题： 　　1. CRM资料分析 　　将某个使用者的历史记录和价值与他的调查问卷系结在一起，寻找内在关联从而更好的定义或描述人物角色。其包括：交易记录、财务资料和人口统计资讯三类资料。 　　交易记录，显示了使用者购买过哪些产品或服务，购买频率，这将强烈影响网站的目标和行为，可作为使用者细分的依据之一。财务资料，使用数字来测量不同人物角色的财务价值，也就能帮助确定各个人物角色的优先级别。财务资料可以与使用者调研问卷关联在一起。人口统计资讯，对于人物角色建立没有很大决定意义，人物角色是由目标、行为和观点驱动的。 　　2. 网站流量分析 　　两种方式：a. 寻找其决定作用的行为模式，分析资料，力图使资料结果和细分群体行为联络起来。b. 把个别用户的点选流和他回复的问卷系结在一起，进一步详细分析。探索使用者的......
为什么要使用资料库
当人们从不同的角度来描述这一概念时就有不同的定义(当然是描述性的)。例如，称资料库是一个"记录储存系统"(该定义强调了资料库是若干记录的 *** )。又如称资料库是"人们为解决特定的任务，以一定的组织方式储存在一起的相关的资料的 *** "(该定义侧重于资料的组织)。更有甚者称资料库是"一个数据仓库"。当然，这种说法虽然形象，但并不严谨。严格地说，资料库是"按照资料结构来组织、储存和管理资料的仓库"。在经济管理的日常工作中，常常需要把某些相关的资料放进这样"仓库"，并根据管理的需要进行相应的处理。例如，企业或事业单位的人事部门常常要把本单位职工的基本情况(职工号、姓名、年龄、性别、籍贯、工资、简历等)存放在表20.6.3中，这张表就可以看成是一个数据库。有了这个"资料仓库"我们就可以根据需要随时查询某职工的基本情况，也可以查询工资在某个范围内的职工人数等等。这些工作如果都能在计算机上自动进行，那我们的人事管理就可以达到极高的水平。此外，在财务管理、仓库管理、生产管理中也需要建立众多的这种"资料库"，使其可以利用计算机实现财务、仓库、生产的自动化管理。

J.Martin给资料库下了一个比较完整的定义：资料库是储存在一起的相关资料的 *** ，这些资料是结构化的，无有害的或不必要的冗余，并为多种应用服务；资料的储存独立于使用它的程式；对资料库插入新资料，修改和检索原有资料均能按一种公用的和可控制的方式进行。当某个系统中存在结构上完全分开的若干个资料库时，则该系统包含一个"资料库 *** "。

? 资料库的优点

使用资料库可以带来许多好处：如减少了资料的冗余度，从而大大地节省了资料的储存空间；实现资料资源的充分共享等等。此外，资料库技术还为使用者提供了非常简便的使用手段使使用者易于编写有关资料库应用程式。特别是近年来推出的微型计算机关系资料库管理系统dBASELL，操作直观，使用灵活，程式设计方便，环境适应广泛(一般的十六位机，如IBM/PC/XT，国产长城0520等均可执行种软体)，资料处理能力极强。资料库在我国正得到愈来愈广泛的应用，必将成为经济管理的有力工具。

资料库是通过资料库管理系统(DBMS-DATA BASE MANAGEMENT SYSTEM)软体来实现资料的储存、管理与使用的dBASELL就是一种资料库管理系统软体。

? 资料库结构与资料库种类

资料库通常分为层次式资料库、网路式资料库和关系式资料库三种。而不同的资料库是按不同的资料结构来联络和组织的。

1.资料结构模型

(1)资料结构

所谓资料结构是指资料的组织形式或资料之间的联络。如果用D表示资料，用R表示资料物件之间存在的关系 *** ，则将DS＝(D，R)称为资料结构。例如，设有一个电话号码簿，它记录了n个人的名字和相应的电话号码。为了方便地查询某人的电话号码，将人名和号码按字典顺序排列，并在名字的后面跟随着对应的电话号码。这样，若要查询某人的电话号码(假定他的名字的第一个字母是Y)，那么只须查询以Y开头的那些名字就可以了。该例中，资料的 *** D就是人名和电话号码，它们之间的联络R就是按字典顺序的排列，其相应的资料结构就是DS＝(D，R)，即一个数组。

(2)资料结构种类

资料结构又分为资料的逻辑结构和资料的物理结构。资料的逻辑结构是从逻辑的角度(即资料间的联络和组织方式)来观察资料，分析资料，与资料的......
django都要建立资料模型有什么用
django都要建立资料模型有什么用

模型有两个方面的作用

一方面决定所建立*资料库*的结构

有哪些栏位，每一个栏位是什么资料型别，是否可以为空null=True

另一方面决定程式如何操作资料库的资料

URL型别，在*网页输入*时需要检查是否满足超连结的条件

blank=True决定在网页输入资料时是否可以为空

而在程式中写入资料时则不检查

并非约束资料的结构

一句话来说，blank是对使用者输入的限制，null是对程式/资料库的限制
实证分析怎么做？！需要什么资料啊？！建立模型什么的该怎么弄啊？！ 5分
灯管寿命取决于镇流器，镇流器不好，再好的灯管也不长寿，如果阀流器跟灯管匹配好，带预热功能，即使市场上一般3-5元的灯管也可以用5年不坏。
为什么在建立资料透视表时，Excel2013无法勾选“将此资料新增到资料模型？ 10分
请检查第一行是否有合并单元格,空白单元格 合并单元格,如果有以上内容 可能会有错误
在资料库系统中,为什么要引入资料模型?
研究开发多媒体资料库要解决的关键技术问题：

a 多媒体资料模型

多媒体资料模型主要采用关系资料模型的扩充和采用面向物件的设计方法。由于用传统的关系模型难以描述多媒体资讯和定义对多媒体资料物件的操作，目前在关系模型扩充方面除了引入抽象资料型别外，较多的采用语义模型的方法。关系模型主要描述资料的结构，而语义模型则主要表达资料的语义，语义模型的层次高于关系模型，后者可以作为前者的基础。目前的研究表明，采用面向物件的方法来描述和建立多媒体资料模型是较好的方法，面向物件的主要概念包括物件、类、方法、讯息、封装和继承等，可以方便地描述复杂的多媒体资讯。

b 资料的压缩和解压缩

由于多媒体资料，如声音、影象及视讯等资料量大，存贮和传输需要很大的空间和时间，因此必须考虑对资料进行压缩编码，压缩方法要考虑到复杂性，实现速度及压缩质量等问题。

c 多媒体资料的存贮管理和存取方法

目前常用的有分页管理、B+树 和Hash方法等。在多媒体资料库中还要引入基于内容的检索方法、向量空间模型资讯索引检索技术、超位检索技术及智慧索引技术等。

d 多媒体资讯的再现及良好的使用者介面

在多媒体资料库中应提供多媒体宿主语言呼叫，还应提供对声音、影象、图形和动态视讯的各种和变换功能。

e 分散式技术

多媒体资料通讯对网路频宽有较高的要求，需要相应的高速网路，此外还要解决资料整合、异构多媒体资料语言查询、排程和共享等问题。

给我分吧，再不详细加我QQ251147830

请简述MyBatis和Hibernate的区别

答：Hibernate和Mybatis都是orm对象关系映射框架，都是用于将数据持久化的框架技术。
Hiberante较深度的封装了jdbc，对开发者写sql的能力要求的不是那么的高，我们只要通过hql语句操作对象即可完成对数据持久化的操作了。
另外hibernate可移植性好，如一个项目开始使用的是mysql数据库，但是随着业务的发展，现mysql数据库已经无法满足当前的绣球了，现在决定使用Oracle数据库，虽然sql标准定义的数据库间的sql语句差距不大，但是不同的数据库sql标准还是有差距的，那么我们手动修改起来会存在很大的困难，使用hibernate只需改变一下数据库方言即可搞定。用hibernate框架，数据库的移植变的非常方便。
但是hibernate也存在着诸多的不足，比如在实际开发过程中会生成很多不必要的sql语句耗费程序资源，优化起来也不是很方便，且对存储过程支持的也不够太强大。但是针对于hibernate它也提供了一些优化策略，比如说懒加载、缓存、策略模式等都是针对于它的优化方案。
Mybatis 也是对jdbc的封装，但是封装的没有hibernate那么深，我们可以再配置文件中写sql语句，可以根据需求定制sql语句，数据优化起来较hibernate容易很多。
Mybatis要求程序员写sql的能力要相对使用hibernate的开发人员要高的多，且可移植性也不是很好。
涉及到大数据的系统使用Mybatis比较好，因为优化较方便。涉及的数据量不是很大且对优化没有那么高，可以使用hibernate