摘要：技術(shù)廣義上，指的是面向?qū)ο蟮膶ο竽Ｐ秃完P(guān)系型數(shù)據(jù)庫的數(shù)據(jù)結(jié)構(gòu)之間的相互轉(zhuǎn)換。狹義上，可以被認為是，基于關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)存儲，實現(xiàn)一個虛擬的面向?qū)ο蟮臄?shù)據(jù)訪問接口。

目前軟件開發(fā)行業(yè)中，無論是移動端開發(fā)還是后端開發(fā)，基本上都會碰到數(shù)據(jù)庫的開發(fā)，這里就談?wù)劰P者對于數(shù)據(jù)庫的感想

在移動端亦或是后端開發(fā)中，很多時候，我們會感覺到無論是 ORM 還是其他方案，都會存在著一些缺點，其實這來源于數(shù)據(jù)庫本身和開發(fā)語言本身的沖突，現(xiàn)代化的語言基本上都是面向?qū)ο箝_發(fā)，面向?qū)ο笫菑能浖こ袒驹瓌t（如耦合、聚合和封裝）的基礎(chǔ)上發(fā)展起來的，而關(guān)系數(shù)據(jù)庫則是從數(shù)學(xué)理論發(fā)展而來的，兩套理論存在顯著的區(qū)別。
數(shù)據(jù)庫最初的時候就是起源于文件，一個程序打開一個文件，然后將一些數(shù)據(jù)存入文件中，最后關(guān)閉文件，從這個需求開發(fā)，發(fā)展出了數(shù)據(jù)庫。目前主流關(guān)系型數(shù)據(jù)庫主要有兩種，一種是基于網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)庫，一種則是嵌入式數(shù)據(jù)庫，這兩種數(shù)據(jù)庫區(qū)別就在于是否存在完善的權(quán)限管理和是否服務(wù)端代碼嵌入到了程序中。
無論是哪種關(guān)系型數(shù)據(jù)庫，開發(fā)者都是通過 SQL 語言和其打交道，主流的 ORM 技術(shù)實際上只是由數(shù)據(jù)庫中查詢數(shù)據(jù)，按條讀取結(jié)果集中每一個字段，然后裝配成對象，或者需要把對象的每一個屬性拆出來，拼湊成SQL字符串，再提交數(shù)據(jù)庫。

廣義上，ORM指的是面向?qū)ο蟮膶ο竽Ｐ秃完P(guān)系型數(shù)據(jù)庫的數(shù)據(jù)結(jié)構(gòu)之間的相互轉(zhuǎn)換。 狹義上，ORM可以被認為是，基于關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)存儲，實現(xiàn)一個虛擬的面向?qū)ο蟮臄?shù)據(jù)訪問接口。這里指的 ORM 是指 Hibernate 這樣的框架，至于 ORM 框架的好處就不說了，ORM 一般情況下，一個持久化類和一個表對應(yīng)，類的每個實例對應(yīng)表中的一條記錄，類的每個屬性對應(yīng)表的每個字段。 但是，這本身 SQL 語言是存在沖突的，我們先來拆分一下要求

數(shù)據(jù)庫需要做 Migration（比如建表，增加字段，刪除字段，描述默認值，增加索引，增加約束等）

表和表通過關(guān)系產(chǎn)生聯(lián)系

SQL 語句可以讓你只選擇自己需要的列

SQL 語句參數(shù)和結(jié)果不保證類型安全

結(jié)果可能是虛的，比如存儲過程和視圖

面向?qū)ο蠛蜕厦娴男袨閷嶋H上是格格不入的，比如將表抽象為一個類，每個類的實例是一行數(shù)據(jù)，看起來確實很完美，但是其實存在一個隱藏的缺陷。

首先，主要的數(shù)據(jù)庫操作，基本都是 CRUD 組成，一般來說，增加、刪除、更新語法都是差不多的，很容易將其抽象，但是查詢就不簡單了，對數(shù)據(jù)的關(guān)注度不一樣，所需要的查詢語句就不同，在針對查詢的方面，ORM 很難覆蓋全部的情況。

其次，面向?qū)ο笾?，存在著繼承，如果兩個對象存在繼承關(guān)系，那如何設(shè)計表結(jié)構(gòu)，

目前的主流 ORM 技術(shù)有好多種，Hibernate 是一種比較典型的如上面所述的 ORM 技術(shù)，Mybatis 則是一種半自動化的 ORM 技術(shù)，這里講一講 Mybatis

Mybatis 不存在 Migration 功能，必須要通過第三方功能支持

Mybatis 只做了 SQL 到對象的映射，類本身不代表數(shù)據(jù)表，而轉(zhuǎn)化出的對象都以 POJO 的形式提供。這實際上是一種字段綁定

也就是說，ORM 本身，需要做兩件事

映射表的本身和遷移

屬性和數(shù)據(jù)庫的字段綁定

Mybatis 由于過于依賴 SQL，因此如果將底層數(shù)據(jù)庫進行替換，則會導(dǎo)致很大的遷移工作量，Hibernate 就不存在這個問題，但是 Hibernate 確實不夠靈活，剛才也講到了 SQL 查詢的問題，因此 Hibernate 如果要做到靈活，實在是代價太大了。兩者各有優(yōu)缺點。

ORM 主要有兩個意義

防止注入，保證 SQL 安全

抽象 OOP，便于開發(fā)

除了上面這兩種 ORM 以外，還有一種更加輕量級的技術(shù)方案，就是提供一整套類似于函數(shù)調(diào)用方式來寫 SQL 查詢，借助 IDE 的代碼提示和編譯器語法檢查，來保證安全，這種方案是靈活度最高的。但是更加繁瑣
在針對防注入方面，通常做法是使用綁定參數(shù)和預(yù)處理語句，避免字符串的拼接，或者采用手段，防止傳入的單引號提前截斷 SQL

由于數(shù)據(jù)庫查詢存在這么大的問題，而且需要保證 SQL 安全，筆者有兩條思路

封裝常用的操作，覆蓋大多數(shù)場景

提供安全的底層手段，解決特殊查詢情況