數據庫隨筆

數據庫隨筆

背景

目前軟件開發行業中，不管是移動端開發仍是後端開發，基本上都會碰到數據庫的開發，這裏就談談筆者對於數據庫的感想

衝突

在移動端亦或是後端開發中，不少時候，咱們會感受到不管是 ORM 仍是其餘方案，都會存在着一些缺點，其實這來源於數據庫自己和開發語言自己的衝突，現代化的語言基本上都是面向對象開發，面向對象是從軟件工程基本原則（如耦合、聚合和封裝）的基礎上發展起來的，而關係數據庫則是從數學理論發展而來的，兩套理論存在顯著的區別。
數據庫最初的時候就是起源於文件，一個程序打開一個文件，而後將一些數據存入文件中，最後關閉文件，從這個需求開發，發展出了數據庫。目前主流關係型數據庫主要有兩種，一種是基於網絡傳輸的數據庫，一種則是嵌入式數據庫，這兩種數據庫區別就在因而否存在完善的權限管理和是否服務端代碼嵌入到了程序中。
不管是哪一種關係型數據庫，開發者都是經過 SQL 語言和其打交道，主流的 ORM 技術實際上只是由數據庫中查詢數據，按條讀取結果集中每個字段，而後裝配成對象，或者須要把對象的每個屬性拆出來，拼湊成SQL字符串，再提交數據庫。

ORM 技術

廣義上，ORM指的是面向對象的對象模型和關係型數據庫的數據結構之間的相互轉換。 狹義上，ORM能夠被認爲是，基於關係型數據庫的數據存儲，實現一個虛擬的面向對象的數據訪問接口。這裏指的 ORM 是指 Hibernate 這樣的框架，至於 ORM 框架的好處就不說了，ORM 通常狀況下，一個持久化類和一個表對應，類的每一個實例對應表中的一條記錄，類的每一個屬性對應表的每一個字段。 可是，這自己 SQL 語言是存在衝突的，咱們先來拆分一下要求

1. 數據庫須要作 Migration（好比建表，增長字段，刪除字段，描述默認值，增長索引，增長約束等）
2. 表和表經過關係產生聯繫
3. SQL 語句可讓你只選擇本身須要的列
4. SQL 語句參數和結果不保證類型安全
5. 結果多是虛的，好比存儲過程和視圖

面向對象和上面的行爲其實是格格不入的，好比將表抽象爲一個類，每一個類的實例是一行數據，看起來確實很完美，可是其實存在一個隱藏的缺陷。

1. 首先，主要的數據庫操做，基本都是 CRUD 組成，通常來講，增長、刪除、更新語法都是差很少的，很容易將其抽象，可是查詢就不簡單了，對數據的關注度不同，所須要的查詢語句就不一樣，在針對查詢的方面，ORM 很難覆蓋所有的狀況。
2. 其次，面向對象中，存在着繼承，若是兩個對象存在繼承關係，那如何設計表結構，

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

1. Mybatis 不存在 Migration 功能，必需要經過第三方功能支持
2. Mybatis 只作了 SQL 到對象的映射，類自己不表明數據表，而轉化出的對象都以 POJO 的形式提供。這其實是一種字段綁定

也就是說，ORM 自己，須要作兩件事

1. 映射表的自己和遷移
2. 屬性和數據庫的字段綁定

Mybatis 因爲過於依賴 SQL，所以若是將底層數據庫進行替換，則會致使很大的遷移工做量，Hibernate 就不存在這個問題，可是 Hibernate 確實不夠靈活，剛纔也講到了 SQL 查詢的問題，所以 Hibernate 若是要作到靈活，實在是代價太大了。二者各有優缺點。

ORM 的意義

ORM 主要有兩個意義

1. 防止注入，保證 SQL 安全
2. 抽象 OOP，便於開發

除了上面這兩種 ORM 之外，還有一種更加輕量級的技術方案，就是提供一整套相似於函數調用方式來寫 SQL 查詢，藉助 IDE 的代碼提示和編譯器語法檢查，來保證安全，這種方案是靈活度最高的。可是更加繁瑣
在針對防注入方面，一般作法是使用綁定參數和預處理語句，避免字符串的拼接，或者採用手段，防止傳入的單引號提早截斷 SQL

針對查詢的問題的想法

因爲數據庫查詢存在這麼大的問題，並且須要保證 SQL 安全，筆者有兩條思路

1. 封裝經常使用的操做，覆蓋大多數場景
2. 提供安全的底層手段，解決特殊查詢狀況