MyBatis从目前最流行的关系数据库访问方法中吸收了大量的优秀特征和思想，并找出其中的协同增效作用。下图展示了MyBatis框架是如何吸收我们在多年使用不同方式进行数据库集成的 开发过程中所学到的知识，并将其中最优秀的思想结合起来，形成这个混合型解决方案的。
接下来的几节将讨论这些不同的数据库访问方法，以及iBATIS从每种方法中汲取的优秀思想。
SQL
MyBatis的核心是SQL。从根本上说，所有的关系数据库都支持SQL,并将它作为与数据库交互的主要方式。SQL是一种简单的、非过程化的语言，用于操纵数据库，其实SQL包含两种语言。
第一种就是数据定义语言（Data Definition Language, DDL),其中包含像CREATE、DROP以 及ALTER这样的语句。这些语句用于定义数据库数据及其设计，包括表（table)、列（column)、 索引（index)、约束（constraint)、过程（procedure)以及外键关系（foreign key relationship)。iBATIS 并不直接支持DDL。虽然许多人的确通过iBATIS成功地执行了DDL，但我们不推荐这样做，因为 DDL通常应该由某个数据库管理小组拥有并控制，应用程序的开发人员无权操纵它。
SQL所包含的第二种语言就是数据操纵语句（Data Manipulation Language，DML)。DML包
括像SELECT、INSERT、UPDATE以及DELETE这样的用于直接操纵数据的语句。最初，SQL被设计 为一种简单得足以让终端用户（end user)可以使用的语言。按照这种设计思想，图像用户界面 就完全不需要了，甚至连应用程序也不需要了。当然，这种情况得回溯到当年那个永远是“黑屏 上闪着光标”的时代了，在那个时代我们才可以对终端用户报以更多的期望。
今非昔比，数据库已经变得太复杂了，不能指望终端用户通过SQL来直接操纵数据库了。你 能想象这样的情况吗：将一大堆SQL语句交给会计部门，然后对他说，“就这些了，查找一下 BSHEET表你就能找到所需要的信息。”这简直是不可能的了。
仅仅SQL本身已经再也不可能作为终端用户的一个有效接口 了，但对于开发人员来说SQL仍 然是一个非常强大的工具。SQL是唯一具有完整的数据库访问功能的方法，所有其他的工具都不 过是该完整功能的一个子集。正是这个原因，MyBatis完全支持SQL，并将它作为关系数据库访问 的主要方式。同时，MyBatis也具有许多其他方法的优点，这些方法包括存储过程和对象/关系映 射工具。
1.老式存储过程
存储过程（stored procedure)也许可以算是为关系数据库编写应用程序的最古老的方式了。 许多遗留系统使用的都是我们现在称为“两层（two-tier)”的设计。“两层设计”包括一个富客户 端界面来直接调用数据库中的存储过程。这些存储过程中可能包含可用于操纵当前数据库的 SQL。除了SQL,这些存储过程还可能含有（通常也的确含有）业务逻辑。与SQL不同，编写这 些存储过程时使用的语言是过程化的，具有像条件语句和迭代语句这样的流程控制语句。事实上， 仅仅使用存储过程就可以创建一个完整的应用程序。许多软件开发商也开发了像Oracle Forms、 PowerBuilder和Visual Basic这样的富客户端工具来支持“两层”的数据库应用程序的开发。
“两层应用程序”的最大问题在于其性能和扩展性。虽然数据库的功能的确非常强大，但它 们往往未必是处理成百上千甚至上百万个用户访问的最佳选择。对于现代Web应用程序来说，对 扩展性的需求并不少见。数据库在并发访问量、硬件资源以及网络套接字等方面的限制，将使得 这种“两层”架构在需要扩大规模时面临失败的危险。此外，“两层应用程序”的部署也是一场 噩梦。除了通常的富客户端部署问题外，复杂的运行时数据库引擎也需要部署到客户端机器上去。
2.现代存储过程
在某些圈子中存储过程仍被认为是三层（three-tier)和八层(N-tier)应用程序（例如Web应 用程序）的最佳实践。但现在存储过程通常被当作来自中层（middle tier)的远程过程调用（remote procedure call, RPC),并且许多性能方面的约束也可以通过建立间接池和数据库资源管理等方式 解决了。在现代的面向对象的应用程序中，存储过程仍然是实现完整的数据访问层的一个行之有 效的设计选择。存储过程在性能方面的确具有优势，因为它们总是能够比任何其他的解决方案更 快地完成数据库中的数据操作。但是，还有比性能更需要关注的问题。
将业务逻辑放在存储过程中通常都被认为是一个糟糕的设计。最主要的原因就在于存储过程 的开发很难符合现代应用程序的架构。它们难以编写、难以测试、同时也难以部署。更糟糕的是， 现代企业中数据库通常由其他的数据库管理小组拥有，并且受到最为严格的变更控制的保护。它 们通常无法快速变更以适应现代软件开发方法学的需要。此外，要用存储过程来实现完整的业务 逻辑，其自身也存在某些限制。如果业务逻辑需要访问其他的系统、资源或用户界面，存储过程 很可能就无法处理所有这些逻辑了。现代应用程序非常复杂，需要更加通用的语言，而不是像存 储过程这样仅仅优化了数据操纵能力的专用语言。为解决这个问题，有些开发商在它们的数据库 引擎中嵌入了像Java这样的更加强大的语言，来编写更加强壮的存储过程。但这其实根本没有解 决问题，它只会使得应用程序与数据库的边界变得更加模糊，并为数据库管理员带来新的负担： 他们现在需要开始担心数据库中的Java和C#了。对于解决问题，这实在是一个错误的工具。
软件开发中经常出现的一个场景就是矫枉过正（overcorrection)。当发现问题时，尝试的第一个解决方案往往是完全相反的方法。这非但没有解决问题，其结果往往是引入等量的完全不同的新问题。例如我们下面要讨论的内联SQL。
系列文章：