大家好，這一篇主要圍繞三個(gè)特點(diǎn)記錄。
mysql數(shù)據(jù)庫(kù)設(shè)計(jì)
- 數(shù)據(jù)庫(kù)設(shè)計(jì)三大范式
- 數(shù)據(jù)庫(kù)表字段類型分析
- 不推薦存儲(chǔ)的數(shù)據(jù)類型
1.數(shù)據(jù)庫(kù)設(shè)計(jì)三大反式。
- 范式分為:3大范式，以及BC范式床玻，第四范式還有第五范式 一共六大范式通常來(lái)說(shuō)滿足與三大范式就基本 足夠 ;
- 注意:項(xiàng)目的數(shù)據(jù)庫(kù)設(shè)計(jì)并不一定要完全滿足與三大范式，有些時(shí)候我們會(huì)適量的冗余讓Query盡兩減少 Join
- 誤區(qū):不是范式越高越就越好 好 => 結(jié)構(gòu)清晰
- 早期:希望數(shù)據(jù)可以足夠的小數(shù)據(jù)量不是問(wèn)題主要分問(wèn)題 現(xiàn)在:希望查詢速度越快越好,同時(shí)操作越簡(jiǎn)單越好沉帮。
1.1 第一范式(1NF)
第一范式要求關(guān)系中的屬性必須是原子項(xiàng),即不可再分的基本類型笨枯，集合、數(shù)組和 結(jié)構(gòu)不能作 為某一屬性出現(xiàn)遇西，嚴(yán)禁關(guān)系中出現(xiàn)“表中有表”的情況在任何一個(gè)關(guān)系數(shù)據(jù)庫(kù)系統(tǒng)中馅精，第一范式是關(guān)系模 式 的一個(gè)最起碼的要求。不滿足第一范式的數(shù)據(jù)庫(kù)模式不能稱為關(guān)系數(shù)據(jù)庫(kù)粱檀。
1.2 第二范式(2NF)
第二范式(2NF)是在第一范式(1NF)的基礎(chǔ)建立起來(lái)的洲敢，既滿足第二范式(2NF)就必須要 滿足第一范式。第二范式(2NF)要求實(shí)體的屬性完全依賴于主鍵字茄蚯。
第二范式(2NF)要求實(shí)體的屬性完全依賴于主關(guān)鍵字压彭。所謂完全依賴是指不能存在僅依賴主關(guān)鍵字一部分 的屬性，如果存在渗常，那么這個(gè)屬性和主關(guān)鍵字的這一部分應(yīng)該分離出來(lái)形成一個(gè)新的實(shí)體壮不，新實(shí)體與原實(shí) 體之間是一對(duì)多的關(guān)系。為實(shí)現(xiàn)區(qū)分通常需要為表加上一個(gè)列皱碘，以存儲(chǔ)各個(gè)實(shí)例的唯一標(biāo)識(shí)询一。簡(jiǎn)而言之， 第二范式就是在第一范式的基礎(chǔ)上屬性完全依賴于主鍵。
1.3 第三范式(3NF)
第三范式(3NF)是第二范式的子集健蕊，既滿足第三范式就必須滿足第二范式菱阵。意思是不存在非 關(guān)鍵字段對(duì)任意候選關(guān)鍵字段的傳遞函數(shù)依賴。
其實(shí)就是把表進(jìn)行拆分缩功，然后在關(guān)系表存上依賴關(guān)系的id晴及。
2. 數(shù)據(jù)庫(kù)表字段類型分析
2.1 字符串類型
char和varchar都是用來(lái)存儲(chǔ)字符串類型的數(shù)據(jù),但是他們保存和檢索的方式不一樣.char屬于固定長(zhǎng)度的字符類型, varchar屬于可變長(zhǎng)的字符類型。
由于char是固定長(zhǎng)度的,所以它的處理速度比varchar快得多,但是其缺點(diǎn)是浪費(fèi)存儲(chǔ)空間,程序需要對(duì)尾行空格 進(jìn)行處理,所以對(duì)那些變化不打并且查詢速度有較高的 要求的數(shù)據(jù)可以考慮使用char類型來(lái)存儲(chǔ)嫡锌。
在mysql中,不同的存儲(chǔ)引擎對(duì)char和varchar的使用原則有所不同 MyISAM存儲(chǔ)引擎建議使用固定長(zhǎng)度的數(shù)列代替可變長(zhǎng)度的數(shù)據(jù)列 InnoDB存儲(chǔ)引擎
建議使用varchar類型,對(duì)于InnnoDB數(shù)據(jù)表,內(nèi)部的行存儲(chǔ)格式?jīng)]有區(qū)分固定長(zhǎng)度和可變長(zhǎng)度,因此使用 char列不一定比 可變長(zhǎng)度的varchar性能好 由于char平均占用空間多余varchar,因此varchar來(lái)UI消化需要處理的數(shù)據(jù)航的存儲(chǔ)總量和磁盤I/O是比較 好的虑稼。
2.2 數(shù)字類型
d 必為主鍵，類型為int bigint unsigned势木、單表時(shí)自增蛛倦、步長(zhǎng)為 1; 注意一下因?yàn)橐恍┍砜赡芤驗(yàn)閿?shù)據(jù)量的關(guān) 系導(dǎo)致主鍵會(huì)很大可能會(huì)超出int的范圍這個(gè)時(shí)候就比較建議使用bigint通常int即可。
注:不過(guò)當(dāng)一個(gè)表數(shù)據(jù)量超過(guò)了500萬(wàn)的時(shí)候或者單表容量超過(guò)2GB的時(shí)候推介分庫(kù)分表;這一步操作是需 要實(shí)先對(duì)于數(shù)據(jù)量在項(xiàng)目上線之后的思考點(diǎn)UNSIGNED屬性就是將數(shù)字類型無(wú)符號(hào)化, unsigned的使用 注意 unsigned tinyint 的范圍就是 0-255跟压。
2.3 時(shí)間類型
- 注意: 默認(rèn)情況下胰蝠，當(dāng)MySQL遇到超出范圍的日期或時(shí)間類型的值或該類型的其他無(wú)效值時(shí)歼培，它會(huì)將該值 轉(zhuǎn)換為“零”值的值震蒋。唯 一的例外是超出了范圍。TIME值被裁剪 到TIME范圍躲庄。
- MySQL允許在DATE或DATETIME列查剖。這對(duì)于需要存儲(chǔ)您可能不知道確切日期的生日的應(yīng)用程序非常有用。在 這種情況下噪窘， 您只需將日期存儲(chǔ)為'2009-00- 00'或'2009-01-00'笋庄。如果存儲(chǔ)這樣的日期，就不應(yīng)該期望得到 正確的結(jié)果倔监，例 如DATE_SUB()或DATE_ADD()需要完整的日期直砂。若要在日期中不允許零個(gè)月或日部分，請(qǐng)啟 用NO_ZERO_IN_DATE模式 浩习。
- MySQL允許您存儲(chǔ)“零”價(jià)值'0000-00-00'作為“假約會(huì)静暂。”在某些情況下谱秽，這比使用NULL值洽蛀，并使用較少的數(shù) 據(jù)和索引空 間。不允許'0000-00-00'疟赊，啟用NO_ZERO_DATE模式郊供。
3. 不推薦存儲(chǔ)的數(shù)據(jù)類型
- 二進(jìn)制多媒體數(shù)據(jù) 將二進(jìn)制多媒體數(shù)據(jù)存放在數(shù)據(jù)庫(kù)中，一個(gè)問(wèn)題是數(shù)據(jù)庫(kù)空間資源耗用非常嚴(yán)重近哟， 另一個(gè)問(wèn)題是 這些數(shù)據(jù)的存儲(chǔ)很消耗數(shù)據(jù)庫(kù)主機(jī)的CPU 資源驮审。這種數(shù)據(jù)主要 包括圖片，音頻、視頻和 其他一些相關(guān)的二進(jìn)制文件头岔。 這些數(shù)據(jù)的處理本不是數(shù)據(jù)的優(yōu)勢(shì)塔拳，如果我們硬要將他們?nèi)霐?shù)據(jù)庫(kù)， 肯定會(huì)造成數(shù)據(jù)庫(kù)的處理資源消耗 嚴(yán)重峡竣。
- 流水隊(duì)列數(shù)據(jù) 我們都知道靠抑，數(shù)據(jù)庫(kù)為了保證事務(wù)的安全性(支持事務(wù)的存儲(chǔ)引擎)以及可恢復(fù)性，都 是需要記錄所 有變更的日志信息的适掰。而流水隊(duì)列數(shù)據(jù)的用途就決定了存放 這種數(shù)據(jù)的表中的數(shù)據(jù)會(huì)不 斷的被 INSERT颂碧，UPDATE 和 DELETE，而每一個(gè)操作都會(huì)生成與之對(duì)應(yīng)的日志信息类浪。在 MySQL 中载城，如 果是支持事務(wù)的存儲(chǔ)引擎，這 個(gè)日志的產(chǎn)生量 更是要翻倍费就。而如果我們通過(guò)一些成熟的第三方隊(duì)列軟 件來(lái)實(shí)現(xiàn)這個(gè) Queue 數(shù)據(jù)的處理功能诉瓦，性能將會(huì)成倍的提升。
- 超大文本數(shù)據(jù) 對(duì)于 5.0.3 之前的 MySQL 版本力细，VARCHAR 類型的數(shù)據(jù)最長(zhǎng)只能存放 255 個(gè)字節(jié)睬澡，如果 需要存儲(chǔ) 更長(zhǎng)的文本數(shù)據(jù)到一個(gè)字段，我們就必須使用 TEXT 類型(最大 可存放 64KB)的字段眠蚂，甚至 是更大的LONGTEXT 類型 (最大 4GB)煞聪。而 TEXT 類型數(shù)據(jù)的處理性能要遠(yuǎn)比 VARCHAR 類型數(shù)據(jù)的 處理性能低下很多。從 5.0.3 版 本開(kāi)始 逝慧，VARCHAR 類型的最大長(zhǎng)度被調(diào)整到 64KB 了昔脯，但是當(dāng)實(shí)際數(shù) 據(jù)小于 255Bytes 的時(shí)候，實(shí)際存儲(chǔ)空間和實(shí)際的數(shù)據(jù)長(zhǎng) 度一樣笛臣，可一旦長(zhǎng)度超過(guò) 255 Bytes 之后云稚，所 占用的存儲(chǔ)空間就是實(shí)際數(shù)據(jù)長(zhǎng)度的兩倍。 對(duì)于圖片的存儲(chǔ)沈堡，如果說(shuō)是 特殊情況可以使用BLOB静陈，但 是通常來(lái)說(shuō)跟推介使用varchar存圖片路徑，而圖片會(huì)放在一個(gè)文件夾中
