DBA成長之路 資料庫設計避坑之路 持續更新

2021-10-18 04:34:29 字數 3020 閱讀 9900

最後

筆者最近正在享受成為一名dba帶來的快感, 同時總結一些自己在設計過程中的理念和一些避坑指南,適用於對資料庫有一定了解和應用的童鞋

注: 以下提到的數字均來自筆者4次資料庫(分別來自cms 出遊旅行 倉儲物流 許可權設計)的設計經驗值

作為一名dba 必要的理論基礎必不可少, 也就說在我們準備設計資料庫時,有些理論是必須掌握的, 相信已經有不少童鞋已經學過或者看過6大設計步驟, 我以具體實際過程闡述這前5個步驟 (第6個步驟筆者需要乙個時間累積,方能給出結果)

理論上db設計過程:

字段設計未雨綢繆如果你需求分析階段準備的很充足 那這一部分就像是乙個中英互譯的過程, 但是一旦有紕漏 那麼它就像一顆定時炸彈

筆者曾經就因為出現對某個表的設計不夠充分, 匆忙開發 結果開發到一半時 猛然發現需要補充乙個字段, 有些朋友應該能體會其中的恐怖之處, 返工是開發過程中最忌諱, 最要命的

解決思路是:如果你能確定某個實體的所有屬性 那麼放心設計就好, 如果但凡你有一點不確定的地方那麼 你至少要準備乙個擴充套件字段以備不時之需(自信是程式設計師的必修課哈哈哈哈)

必須字段其實有時候設計表設計多了 你會發現 總會有這麼幾個欄位都是通用的:id, create_time, modify_time, create_by, modify_by, 不過有時候也很苦惱 無論你維護幾個欄位都需要這5個字段去協助, dba也很苦呀…

盡可能使用編碼格式為utf8mb4, 怎麼說呢, 其實也是未雨綢繆, 因為現在有些場景會用到emoji表情

筆者曾經寫cms 時候用到過emoji 當時設計的是utf8編碼 導致sql解析出錯, 忙活了好一陣子,原因在於emoji 是占用四個位元組的

平常使用uf8是占用1-3個位元組, 芳名utf8mb3而utf8mb4是它的超集 支援1-4位元組 所以能夠有效解決表情儲存問題,

給create_time 和 modify _time新增預設值

這個是筆者苦逼的開發經歷總結得出, crud的業務有時候需要記錄操作的時間, 之前沒有注意mysql的預設值, 自己徒手更新時間 有時候還經常忘記, 痛苦好一陣子

首先這兩個欄位的存在意義你會下面看到, 另外他們都是datetime型別有了這個前提, 我們再說具體設定create_time最好設定成:default current_timestampmodify_time設計成default null on update current_timestamp有了這兩個預設值 開發直接起飛, 完全不需要我們去考慮維護, mysql自動更新 非常實用!!!

字段命名

看似好像是英文互譯, 但是也有些需要注意的地方

資料庫名 表名 欄位名 變數名 統一小寫,部署過web服務的童鞋應該頗有感悟, windows的mysql預設不區分大小寫但linux的mysql是區分大小寫的所以為了避免節外生枝, 請盡量使用小寫

簡明易懂,雖然我們提倡欄位的命名盡量簡潔, 但是不能過於間接導致閱讀障礙, 良好的習慣是不要使用單詞的簡化形式除非大家都懂 比如information -> info , student -> stu因為我們開發的資料庫 畢竟要給各方面人員檢視和使用 應該避免這種溝通成本

表達是否的含義盡量不要使用is做字首 而採用_status字尾標識, 這個其實我閱讀阿里巴巴開發者規範 和阿里巴巴資料庫設計規範 得出的結論

不過細心的同學就會發現乙個有意思地方, 在開發者規範中提到 由於rpc在逆向解析的時候 對is開頭的boolean會無法識別, 所以阿里不建議我們使用is開頭, 但是在資料庫規範的中 阿里強制我們使用is做boolean欄位的字首 這就很有意思了 口說無憑

怎麼樣, 有沒有感覺這個世界很魔幻, 魔幻在於我們在開發中要求資料庫和class一 一對應 (心想: 尼瑪, 我tm像做夢一樣)

所以筆者的解決想法是, 既然互相衝突, 所幸不如換一種標識方式, 想了很久決定採用xx_status字尾命名

好處是:

1.至少我們看到這個字尾 本能想到它是個狀態字段 或者 列舉字段, 其實想想 boolean其實也是一種列舉, 當然資料庫這裡應該是tinyint型別

2. 有效避免rpc逆向解析問題

筆者自我研究的思路 諸位隨意哈

避免保留字

這也是筆者在開發早起開發過程中遇到的問題, 當時是因為desc這個字段, 從命名上似乎並沒有什麼問題, 但是插入資料庫的時候頻繁報錯, 查詢度娘才知道 它是mysql的保留字 早起筆者都是手寫sql建立表 所以沒有加``的習慣, 導致出錯, 現在有些工具已經能夠識別這些問題 並幫我們自動解決

但是最好還是避免使用desc這樣的字段 而應該採用全稱!

上面就是筆者從開始設計資料庫歷程中的一些真實坎坷, 希望能幫助到大家及時避坑,

這篇將持續為大家更新, 其中第六步驟還需筆者一些經驗磨練 方能給出滿意的結論, 老規矩 莫要白嫖 !

ORACLE學習之路 資料庫的儲存結構

最近特別忙,連上網的時間都沒有。今天把oracle的儲存結構介紹一下。oracel資料庫中的資料邏輯儲存在tablespace中,同時物理地儲存在資料檔案中。要了解資料庫的儲存結構,就要先了解資料庫中的資料是存放在 以及存放資料庫的邏輯空間名。oracle中對資料的儲存分了四層,根據儲存大小以及從屬...

成長軌跡 資料庫課程設計總結

這個本該是在專案完成之後才寫的,但是因為一些主客觀原因,本專案還沒有實現完成,因此沒有 可執行的 由於平時接觸的都是一些私人專案,這些專案大都是一些類庫,其他人的交流相對可以忽略不計,因此也就不考慮規範化的文件。實際上從學習的經歷來看,我們接觸的知識體系都是屬於比較老或比較傳統的,與現在發展迅速的i...

資料庫設計 資料庫設計之欄位冗餘

學過資料庫設計的同學都知道,資料庫設計有三大正規化,但是在實際工作中,三大正規化很難被嚴格的執行。本文將給大家介紹一種常見的 違反正規化的資料庫設計方案 字段冗餘1 經典示例先來看乙個經典的例子,在一些 系統裡,要顯示已購買的訂單,一般會顯示訂單號 下單時間 訂單金額 商品名稱等,如下圖。正常我們如...