MySQL&PostgreSQL設計規範
1. 設計工具
使用Navicat Data Modeler進行數據庫設計，使用*.ndml文件交流設計細節，不允許直接操作數據庫進行修改
修改數據庫一定要同步更新本地的.ndml文件，避免因開發環境異常而導致數據庫丟失，demo測試數據或初始化數據要以sql腳本協議代碼中*
字符集：統一使用utf-8字符集, 按中文排序
2. 命名規範
2.1 數據庫名
- 使用蛇底式命名法(snake_case)
- [部門名]_項目名, 部門名可省略
2.2 表名
- 使用蛇底式命名法(snake_case)
- 名詞表名應使用單數形式 (辨認、書寫一個單詞的複數形式，更困難)
- 表名儘量簡短 (例如用戶表，表名應爲user，而非user_info, 當伴隨多個附屬表時便於定位主表)
- 表名通常使用名詞
2.3 字段名
- 使用蛇底式命名法(snake_case)
- 字段名儘量簡短
- 可使用衆所周知的單詞簡寫(例如 desc)
- 不可使用保留字
class, desc等
通用字段
特殊含義字段，除非特別需要，請使用約定名稱
- id 表的主鍵爲id, 不需要增加類似user，device之類的前綴，例如userid
- 表名_id 邏輯上的外鍵id，不建議使用外鍵定義
- name 記錄的名稱，是id的別名，一般用於友好顯示
- create_time 記錄的創建時間
- update_time 記錄的更新時間
- expire_time 記錄的過期時間
- is_deleted 記錄的刪除標記
- desc 記錄的描述，描述通常有長度限制，是對name的進一步說明
- comment 記錄的備註，通常是備忘信息，長度較長
3. 數據類型規範
- 優先選用數值類型
- 如果可以儘量不允許輸入null
數字類型選擇
- 估算範圍優先選擇存儲空間小的類型 (降低數據存儲，降低索引存儲)
- id應使用自增類型
- 對與金融貨幣應採用準確的定點型 (防止計算誤差)
- 用整型代替boolean類型 (mysql boolean實際實現爲tinyint(1),不會節省空間，但會降低擴展性)
- 需要進行模糊查詢時不應使用數字類型, 而應使用字符串(例如，身份證號，電話號)
字符串與字節流
MYSQL
- 長度變化不大的字符串用char
- 長度變化較大的字符串用varchar
- 需要有默認值使用varchar，不選用text
- 能用varchar，不用text
- 非可視字符數據應使用字節流類型
POSTGRESQL
- 儘量使用text
- 需要限定最大長度時使用varchar
時間時期類型
- 只需要時分秒或年月日的情況下可以選擇date
- 需要秒級精度時儘量選用timestamp類型, 不建議使用time(可使用數據庫的相關時間函數，但需注意對數據庫服務器的時區依賴)
- 可使用bigint
- 不允許使用varchar
## 整型
SQL標準 - smallint - integer bigint
postgresql 有符號 char(1)[1B,charactor(1)]替代 smallint[2B,int2] char(3)替代 integer[4B,int,int4] bigint[8B,int8]
自增 smallserial[2B,serial2] serial[4B,serial4] bigserial[8B,serial8]
postgreql serial並非真實類型, 內部實現爲一個integet+一個自增serquence實現，可用\d 查看錶結構檢查
mysql tinyint(1字節) smallint(2字節) mediumint(3字節) int(4字節) bigint(8字節)
## 浮點型
postgresql real,float4(不準確,4字節,6位) double,float8(不準確,8字節,15位) decimal,numeric(準確，變長，任意精度，最多1000)
mysql float(4字節,6位) double(8字節,15位) decimal(16字節，準確，定點)
## 字符型
postgresql char(n),character(n)(定長,不足補白,最大1GB) varchar(n),character varying(n)(變長,最大1GB) text(變長, 無長度限制)
注：postgres中char與varchar無性能差別，但char可能比varchar多佔用空間
mysql char(n)(定長,不足補白,最大255字節) varchar(n)(變長,v5.0.3最大255之後最大65535) tinytext(最大255) text(最大65535) mediumtext(最大16777215) longtext(最大429496729)
注：mysql中char比varchar性能更高
## 布爾型
postgresql bool,boolean(從擴展性角度，不建議使用)
mysql bool,boolean(從擴展性角度，不建議使用)
## 時間日期
postgresql date(4字節, 年月日) time(8字節，時分秒毫秒) timestamp(8字節) timestamptz(8字節, 時間戳帶時區) timetz(12字節, 時間戳帶時區) interval(12字節, 時間間隔)
mysql year(1字節, 年) date(3字節, 年月日) time(3字節, 時分秒) datetime(8字節) timestamp(8字節, 有自動更新特性)
## 字節流
postgresql bytea(變長，字節流)
mysql tinyblob blob mediumblob longBlob
## 特殊數據類型
postgres
money 數據庫級別提供併發機制，準確精確計算，但輸出與幣種有關，且數據庫全局設置，不建議使用
bit bitvar,bit varying 位串類型，可在位級別進行長度控制
4. 索引選擇
4.1 索引添加
- 數據表id必須加索引
- 表示唯一數據的字段應該加索引(除非確定肯定不會在查詢中用到)
- 可能作用篩選where語句，排序order by的部分必須加索引
4.2 索引類型
Hash索引: 內存佔用多, 但單條記錄查詢效率最高，不支持排序
B-Tree索引: 查詢效率較高，支持範圍查詢及排序
- 需要支持排序的索引須使用B-Tree索引，根據場景需注意B-Tree的排序設置
- 需要聲明唯一性的索引須使用B-Tree索引
- 需要比較，判等操作時使用B-Tree索引
- 字段值特別長，且只需要等值查詢時使用Hash索引
- 按時序插入的數據，且只需要等值及範圍查詢時使用BRIN索引
- 空間幾何類型數據使用GiST或SP-GiST索引
- 全文檢索使用BRIN索引
5. 備註規範
5.1 表備註
- 表名不能準確表達表用途時應備註說明
5.2 字段備註
- 具有量綱單位的字段，應在備註中給出字段對應的單位
- 枚舉或編碼數據給出常見值及對應的含義
- 字段名如果使用縮寫，備註應給出縮寫全稱
6. 數據引擎選擇(PostgreSQL不需考慮)
不同的數據庫對數據庫引擎的支持不同，因此考慮數據庫引擎選擇的優先級別規範
常見MySQL數據庫
MySQL(閉源風險) ==> Infobright (mysql的數據倉庫方案)
MariaDB
Percona
AliSQL
postgres ==> Greenplum(postgres的數據倉庫方案)
常見數據庫引擎使用優先級
Xtradb=>InnoDB (全事務型存儲引擎，事務方面支持較好)
TokuDB (新型事務型存儲引擎，寫入性能高，存儲壓縮比高，適合寫多讀少的場景)
Archive (適合歸檔類數據，讀少，寫多，可考慮用數據倉庫類方案)
MEMORY (適合可忍受丟失，且訪問頻繁的數據，可用redis，memcached等替代方案)
Aria(原名Maria引擎)=>MyISAM (MYSQL8.0開始不再維護，不推薦使用)
SphinxSE引擎 (是和全文搜索)
7. 開發測試環境與部署環境分離
- 開發測試環境
服務器：測試用例統一使用數據庫，如 10.0.30.201
注意：數據隨時刪除不應影響測試，測試用例代碼包含所需測試數據 - 演示與生產環境
服務器：如默認使用10.0.30.209 ，具體視實際情況而定
注意：應有可靠備份，數據不因誤刪除而影響