什麼都不談之一，從最容易，最基礎的數據庫設計說分佈式，架構，開發，管理

前言

不論是開會，仍是與人聊技術。最怕的，最煩的，最噁心的就是開口就是： 分佈式，大數據，高併發，微服務解決方案。 遇到這樣的人，開會直接就走了。聊天直接看手機。 想問句：數據庫設計好了嗎？

新任務是維護一個老項目或者參與一個正在開發的新項目。 第一個要求就是：先提供數據庫設計相關文檔。 架構設計很差，只須要換一套架構。由於有封裝，ioc，aop，模塊等等技術重構就行了。仍是比較好的處理。

數據庫設計很差，不只須要從新設計數據庫，應用層的業務代碼，web應用，app都很可能大改。

維護的成本代價是在太大了，維護成本甚至大於重寫成本。只能項目重寫。不多公司能給你時間，人力，資源重寫。

就算你技術在怎麼牛，能力在怎麼強，架構在怎麼兼容，都無用。沒法逆天。因此數據庫設計很差的項目。一概不接。不敢當這救世主。

開發無非就是基於數據庫或者 領域驅動模型。

領域驅動模型 這種敏捷的開發方式，對整個團隊要求過高了。這裏不詳談。至少在中國能基於 領域驅動模型開發的團隊實在太少了。 基於數據庫開發，纔是大多團隊的首選。

技術這東西，只是少數人在玩。數據庫設計關聯的人太多了。

1. 技術
   1. 在大公司，對於每一個技術點。都有專業的團隊進行維護，管理。好比bat都有MySQL內核團隊，運維團隊，中間開發團隊等等。
   2. 在小公司，有一個大牛帶幾個小牛，基本能夠搞定公司的技術了。
   3. 技術攻關對整個業務層影響不大。好比使用mycat分庫分表。上層的業務繫有感知嗎？
2. 數據庫設計
   1. 關聯的人太多了
      1. 須要龐大的開發人員實現，維護。
      2. 測試人員測試時，須要對測試數據進行數據正確性校驗，數據初始化等
      3. DBA須要......
   2. 因此數據庫設計是技術與業務的半邊天
   3. 雖然大多公司都有數據庫評審，可是基本是過場子
      1. 領導從不重視
      2. 技術人員不重視
      3. 從不讓測試人員參加
      4. 從不讓DBA參加
      5. 產品不肯意參加

數據庫設計維護的複雜度

1. 正式環境，數據量大,分佈式的狀況下。
   1. DDL的維護十分複雜，謹慎。
      1. 須要在測試環境反覆的校驗
      2. 造成ddl更新文檔。
      3. 須要在每一個分片節點執行
      4. 須要在凌晨的時候進行 在線ddl操做，可能會形成線上服務數據庫操做超時狀況
      5. 不能當即執行刪除字段操做。當刪除了字段，可能明天這個字段不須要刪除。如何回滾。
   2. 添加字段數據預準備
      1. 添加的字段不能爲空，必須賦值，可能須要經過某種複雜的方式得到數據。
   3. ddl操做出問題..... 數據處理出問題.....
2. 業務層的複雜度
   1. 至少java 開發。基本模式是 一表，一個實體類，一個mapper.xml文件，一個dao，一個server，一個action，一個頁面。好大的開發工做量。
   2. 關聯查詢操做多，
   3. 業務代碼十分複雜
   4. 等等
3. 原則是 數據庫能他.. 能不動就不動。

上面的問題是沒法避免的。可是儘可能不要出現ddl操做，在開始設計或者階段性設計的，儘可能的設計好。仔細的分析需求，不要怕麻煩產品。

痛點總結

不要說 數據量的問題。這徹底是藉口。 互聯網公司，大多基礎業務的複雜度都不高，不要說業務複雜。這也是藉口。

沒法整合表

描述： 一個第三方支付系統。須要對接不少支付渠道。好比銀聯，銀行，微信，支付寶等等十來個。由於項目負責人與開發者。沒法概括在一塊兒，並且開始階段就只有銀聯，銀行，微信，支付寶 。爲每一個支付渠道設計了一張表。每一個表保存渠道與商戶的信息。 問題： 後來渠道愈來愈多，表愈來愈多，應用層與數據庫維護愈來愈複雜。

1. 基本模式是 一表，一個實體類，一個mapper.xml文件，一個dao，一個server，一個action，一個頁面。開發與維護工做量十分龐大
2. 每一個支付渠道的流程實現個有一套。
3. 表愈來愈多，越沒法理解。

4. 實現十分複雜，耦合度十分高。沒法進行性能優化。

解決：

1. 認真分析業務，把全部表合成一張，增長識別渠道的字段就行了。業務層寫了一個簡單內核 結果： 整個項目代碼乾淨多了。數據庫瘦身了，單表量變多了。之後在須要添加新的渠道，不須要那麼複雜了。
2. 由於表從新設計，業務層也重寫。若是開始就這樣設計，開發工做量（測試）也就一人三十五天。而重寫花了一人一百四十多天（設計，分析，數據遷移等等）。
3. 技術提升效率，釋放時間，下班萬歲。

經驗： 模塊的表設計應該控制在五張以內，最多不能超過八張。若是出現這種狀況是否表設計有問題。是否對業務理解透了。

字段設計問題

1. 該和 的字段不和

請看sql中的whre語句

SELECT * FROM stats_room_energy_day s WHERE (
			( s. YEAR = 2017 AND s. MONTH = 1 AND s. DAY = 2 	AND s. HOUR >= 3 )
			OR ( s. YEAR = 2017	AND s. MONTH = 1 AND s. DAY = 2	AND s. HOUR <= 10 )
		)
		and s.area_type = 2

把年，月，日，時個爲一個字段。使之一個字段差分超過四個以上。數據庫多四個字段，實體類多個屬性，頁面展現須要拼接...... 老胡問: 爲何這樣設計 設計者： 這樣方便查詢..... 老胡問： 開發是否很麻煩。 設計者： 還好，耽誤了不少時間（爲了維護這點，編寫了大量代碼），可是查詢方便 老胡問： 性能了？ 四個月以後..... 設計者： 業務抗不住了，性能也抗不住了

只須要稍微改變下

<select>
	<foreach collection="list" item="item"  separator="UNION">
		SELECT * FROM stats_room_energy_day s WHERE time > #{startTime} and time  < #{endTime} and s.area_type = 2
	</foreach>
</select>

連表問題

互聯網數據庫方面是不少軍規的。這些軍規主要是針對 互聯網狀況下高併發，數據量大 其中有一條是 儘可能不要連表查詢。

1. 連表對性能不友好 不少程序員都喜歡用一條複雜sql語句解決問題。不想用其餘的方式去實現。並且程序員每每都不懂sql優化。因此大量的sql語句性能十分差。
2. 連表對維護不友好 問題案例： 這仍是一個比較簡單的sql語句。這樣的語句誰能維護。看懂了sql語句，須要對整個業務流程進行一次梳理。接受者也不會知道這條sql語句業務做用幹什麼。應該如何維護

   SELECT o.* FROM t1 o WHERE  NOT EXISTS 
   		( SELECT 1 FROM t2 oe WHERE 
   		( oe.operation = 'aaa' OR oe.operation = 'bbb' ) 
   		AND 
   		flag = 0 AND o.order_id = oe.order_id )
     AND ( o.pay_person = 1 OR o.pay_person = 2 OR o.pay_person = 3 OR ( o.pay_person = 4 AND o.pay_status = 1))
   	AND o.grab_time < date_sub(now(), INTERVAL 5 HOUR)
   	AND o.order_type = 3
   	AND o.order_status = 5

LIMIT 1000;

3. 連表對微服務不友好
微服務會把每一個業務模塊化。因此模塊之間的數據庫是獨立。沒法進行連表查詢
4. 連表對分庫分表很差友
已知現有的數據庫中間件，對sql語句的解析能力有限，沒法解析複雜的sql語句。只能全片執行或者不執行。全片執行的結果。正確性有待考量。