寫一個「特殊」的查詢構造器 - (前言)

文章目錄

寫一個「特殊」的查詢構造器 - (前言)

寫一個「特殊」的查詢構造器 - (1、程序結構，基礎封裝)

寫一個「特殊」的查詢構造器 - (2、第一條語句)

寫一個「特殊」的查詢構造器 - (3、條件查詢)

寫一個「特殊」的查詢構造器 - (4、條件查詢：複雜條件)

寫一個「特殊」的查詢構造器 - (5、聚合函數、分組、排序、分頁)

寫一個「特殊」的查詢構造器 - (6、關聯)

寫一個「特殊」的查詢構造器 - (7、DML 語句、事務)

寫一個「特殊」的查詢構造器 - (8、單元測試、收尾工做)

更新

此項目已經從 WorkerA 中拆分爲獨立項目，完整代碼請到 wazsmwazsm/DB 中查看。

前言

對於後端程序員來講，數據庫操做是必備知識，對數據的增刪查改也是業務中最廣泛、頻繁的操做。

對於關係型數據庫，如 Mysql、Postgresql 等，咱們可使用 SQL (Structured Query Language) 來操做咱們的數據，如 「SELECT * FROM test;」 這類的 SQL 語句，大部分的編程語言如 PHP、Python、go 等都提供了相應的數據庫擴展，能夠方便的進行數據庫鏈接、執行 SQL 獲取結果。

可是，直接使用基礎的擴展效率並不高，每次都要建立鏈接、手動寫 SQL、對執行結果進行判斷、將查詢獲得的數據進行處理等，代碼的重用性和維護性並非很好，在多人開發的時候更是不能保證代碼質量。而在項目開發中，咱們想要的是一個更好用的可維護的工具，此時，對代碼的封裝、模塊化就顯得尤其重要，因而出現了兩種方案：查詢構造器，對象關係映射。

• 查詢構造器 (query builder)，顧名思義，它的目的就是以簡便的形式構造、執行 SQL，爲查詢數據庫的業務提供了方便好用的接口，一些知名的 web 框架如 PHP 的 Laravel、CodeIgniter、ThinkPHP 等都提供了好用的查詢構造器。
• 對象關係映射 (ORM) 是一種更面向對象的數據模型化操做，將數據庫的數據映射成對象模型，數據庫的直接操做對開發者透明，開發者只需關注對象模型便可，更符合面向對象程序思惟。一樣，不少框架也提供了 ORM 的方式去操做數據。

爲何要寫查詢構造器，個人需求是什麼

寫這個查詢構造器的原由是 workerman，一個由 PHP 編寫的、能夠常駐內存的 Socket 框架。

當時選用 workerman 去作一個 webAPI 的項目，針對 workerman 的環境編寫了一個簡單的 http 框架 WorkerA，一是沒有找到合適的 (在一個非典型 web 環境中，想要一個相似 laravel 那樣方便的查詢構造器)，二是想要鍛鍊本身，因而選擇了本身去寫這個查詢構造器。

現在該查詢構造器已經完工，完整代碼在個人框架核心代碼中： 查看

Q&A

Q：爲何選擇查詢構造器而不是 ORM

A：對於我本身的需求，我須要一個簡單好用又快速的工具，ORM 的性能和複雜性顯然不合適。

---

Q：該查詢構造器「特殊」在何處

A：區別於典型 web 的一次 HTTP 請求的代碼運行週期，這個查詢構造器除了可使用在普通的 web 環境中，還支持常駐內存的環境，支持斷線重連 (這個很重要)

---

Q：爲何選 PHP

A：由於我本身用 PHP 開發最多，重要的是 workerman 是 PHP 編寫的。

---

Q：支持哪些數據庫

A：目前支持了 Mysql、Postgresql、Sqlite 這三個數據庫，並且所有經過了單元測試

---

Q：好的使用實踐？

A：我在 workerman 的環境中使用的是單例模式，每一個進程一個數據庫鏈接單例模型。典型 web 環境下按照通常的查詢構造器處理就行。一樣常駐內存的情景能夠本身寫連接池之類的功能，固然這和查詢構造器自己沒有關係，一切由你的需求來決定。

需求和技術的選擇 (想一想本身想要什麼)

底層驅動的選擇：

• php 提供了 mysql 和 pgsql 這些經常使用數據庫的擴展，可是每一個擴展暴露出的接口都不大同樣，封裝不便，pass
• php 的 PDO 提供了多種數據庫的底層驅動，統一了訪問接口，prepare 方法能夠有效的防止 SQL 注入，就選它

錯誤異常處理：

• 使用 PHP 的 try catch 機制，使用內置的異常和 PDO 的異常進行異常拋出

代碼結構的設計：

• 查詢構造器要支持多個數據庫，咱們要把相同的部分 (查詢等) 封裝起來，將不一樣的部分 (不一樣數據庫的鏈接和設置) 獨立開來，那麼只需建立一個基類 (封裝 PDO 的操做)，每一個數據庫單獨創建一個類繼承基類，將各自差別的部分重寫便可。

SQL 的構建：

• sql 的構建屬於字符串的操做，構建 sql 便是構造字符串，PHP 有豐富的字符串處理函數

好用和性能的均衡考慮：

• 有些工具好用可是性能不必定好 (好比正則表達式)，固然並非說爲了語言層面的極致性能而放棄一些便易性，查詢構造器的瓶頸通常在於鏈接數據庫的網絡消耗和數據庫對 SQL 的執行上。那麼咱們就以此做爲平衡點，只要不比平衡點慢，咱們能夠選擇更方便開發的方式寫代碼。

測試：

• 選擇 phpunit 做爲單元測試工具，以可測試爲前提拆分代碼爲最小單元，提高代碼的可維護性

整體思路

進行相關的需求分析和技術選擇後，咱們得出了構建查詢構造器的大概的思路：

• 基於 PDO
• 經過字符串操做構建 SQL
• 將構造好的字符串交給 PDO 執行，獲取結果
• 以繼承、重寫的模式搭建代碼的架子
• 錯誤異常處理
• 編寫單元測試

理清思路，開始幹活。

(本系列文章默認您已經掌握 PHP、PDO、SQL 的基礎知識)