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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

也就是說(shuō)，ORM 本身，需要做兩件事

映射表的本身和遷移

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

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

ORM 主要有兩個(gè)意義

防止注入，保證 SQL 安全

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

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

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

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

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