以下內容僅是個人工作至今的一些總結,不代表權威,后續會有一些針對具體業務需要設計的表結構后面會說,這里只是針對所有的表的一些比較通用的,我覺得比較不錯的方案,僅供參考,歡迎大家交流學習,謝謝.
0.也是最重要的,所有表必須有備注,必須有備注,必須有備注.
1.要有唯一索引UNIQUE,普通索引看情況增加
唯一索引是最后一道防線了,高並發的時候如果前端,代碼,緩存都沒有攔截住重復數據這里就會起到關鍵的作用
2.各個表中的同一個外鍵字段命名一定要一致(eg:商品編號(product_id),在商品屬性表中,活動商品表中,供應商商品關聯表中等等標中必須都叫product_id)方便維護
如果不一致則在后期表多的時候,維護起來特別麻煩,浪費時間,而且還不爽
3.數據庫引擎最好都是innodb
有人說我不需要事務為可以不用innodb,是的,但是有些業務是一開始完全單表不需要事務,你設置了MyIASM,過了好久突然這些表需要用到事務了,你肯定不會記得當時這個表是MyIASM,然后就上線了,然后由於各種原因,數據不完整,也挺惡心的
可以參考文章:http://www.2cto.com/database/201503/385669.html
4.命名一定要駝峰,經典的駝峰,沒啥說的
5.觸發器啊存儲過程啊能不用就別用,數據庫遷移或者換數據庫的時候比較煩人
6.如果需要標識數據的狀態的字段一個就可以了,我的話就命名state,0未審核-1刪除1,2,3,4,5..... 只要有涉及需要標識數據狀態的往上增加就可以了,不要覺得一開始是5個節點,待審核(1),主管審核(2),經理審核(3),財務審核(4),完成(5)
之后在3后面增加了一個節點,總經理審核,你就要把總經理審核變成(4),然后,財務審核(5),完成(6),這樣老數據的狀態就全都亂了,正確的排序就應該是往后增加
待審核(1),主管審核(2),經理審核(3),總經理審核(6),財務審核(4),完成(5),以此類推舉一反三,還有不要弄一些什么是否刪除字段,是否提交,是否....是否...之類的字段,一個狀態都可以標識出來了
7.表越大越需要一些冗余字段,大表跨表查詢太慢了,還有如果用一些mycat之類的分庫分片軟件也是需要冗余字段的,不要覺得冗余不好,都是看具體情況具體分析的.
8.所有表需要有自增id,名字就交id即可
9.涉及有狀態的數據的表必須有一些流程記錄的表與之對應,一個信息從開始到結束的過程都要記錄下來.
10.不是特別重要,我的習慣,所有的表都要有以下幾個字段
create_user 創建人,create_time varchar(20) 創建日期
update_user 更新人,update_time varchar(20)更新日期
remark 備注說明的意思
這幾個字段都是varchar字段標紅的是我想說的,一開始time相關的字段用的都是date或者timespan,后來開發中由於好多時候系統內,系統外對接,之類的原因導致時間轉換的地方比較麻煩,最終還是改為varchar了,真是太方便了,2017-04-18 17:30:00這個標准的格式19個就夠了,向上湊整20^_^
11.未完待續吧肯定還有只是目前想不起來了,本篇就命名"數據庫表基本設計規則(一)"應該會有后續
歡迎交流學習,如需轉載請注明出處,謝謝.
----------2014-04-21--修改了第二條的一些錯別字增加了舉例