本篇內(nèi)容主要講解“MySQL的表設(shè)計(jì)與使用”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“MYSQL的表設(shè)計(jì)與使用”吧!

創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比佳縣網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式佳縣網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋佳縣地區(qū)。費(fèi)用合理售后完善，十載實(shí)體公司更值得信賴。

一個(gè)表的設(shè)計(jì)，個(gè)人愚見，首先要看業(yè)務(wù)，以及你選擇的架構(gòu)，業(yè)務(wù)量是大還是小，業(yè)務(wù)是互聯(lián)網(wǎng)性質(zhì)的，還是傳統(tǒng)性質(zhì)的，業(yè)務(wù)是可變化較大的，還是比較固話的，等等，當(dāng)然可能還有更細(xì)分的，從數(shù)據(jù)庫的角度來看，你是準(zhǔn)備使用哪種數(shù)據(jù)庫，決定是可以分庫分表，還是分區(qū)表，或者冷熱表，在或者使用特殊的某些小手段，來讓你的表更清爽一些。同時(shí)不同的數(shù)據(jù)庫也賦予表設(shè)計(jì)更多的余地，所以我一直在希望開發(fā)和DBA能緊密結(jié)合，因?yàn)殚_發(fā)大部分是不知道各種數(shù)據(jù)庫的門道，和一些奇特的功能，而DBA可能并未有開發(fā)人員的對業(yè)務(wù)理解的深刻，如果二者結(jié)合，則設(shè)計(jì)的表會比單方面設(shè)計(jì)的表要好的多。也更值得推敲。

下面就說說，在MYSQL 表設(shè)計(jì)中的一些見過的，小麻煩，以及如何化解。

1拿到的數(shù)據(jù)中，MYSQL的表竟然沒有主鍵，根據(jù)和開發(fā)人員交流，發(fā)現(xiàn)他們有一個(gè)很有趣的想法，認(rèn)為沒有主鍵的表的插入速度會快，因?yàn)樗麄円蟛迦氲乃俣纫欤鶕?jù)他們以往的ORACLE的經(jīng)驗(yàn)是這樣認(rèn)為的。當(dāng)時(shí)和他們解釋，他們提出ORACLE的表沒有主鍵會在表上默認(rèn)產(chǎn)生ROWID，所以對這樣的信息記錄的表（弱業(yè)務(wù)）是可以這樣設(shè)計(jì)的，先不提在ORACLE  這樣是否OK，在MYSQL 中我只問了他們一個(gè)問題，“請問這個(gè)表還需要查詢嗎”，回答是當(dāng)然。 

根據(jù)他們的回答，我建議，既然要查詢，則需要建立主鍵，或者退而求其次建立唯一索引。并解釋了為什么(MYSQL的表的原理，以及底層結(jié)構(gòu)），開發(fā)人員表示認(rèn)同，隨即添加主鍵。

其實(shí)之前也是遇到過這樣的情況，但當(dāng)時(shí)解釋的角度就是一句，規(guī)章制度，軍規(guī)，或者在解釋MYSQL的復(fù)制必須要設(shè)置主鍵，等等。但開發(fā)人員給我的回饋是不是太好，這讓當(dāng)時(shí)我的反思，在解決問題的時(shí)候要站在對方的角度，來處理，對方會更好的接受和理解，并且還會和你一條心的解決，因?yàn)檫@設(shè)計(jì)了他自己的利益。

2 在參與一個(gè)系統(tǒng)的設(shè)計(jì)時(shí)，開發(fā)人員將一個(gè)表的主鍵設(shè)置為多個(gè)列，根據(jù)業(yè)務(wù)邏輯來看，他這樣做是沒有問題的，地區(qū)編碼，加客戶編碼，加客戶的類型，是能決定這個(gè)表中客戶的唯一性，雖然從MYSQL本身的角度不建議這樣做，但開發(fā)人員提出，那業(yè)務(wù)已經(jīng)這樣設(shè)計(jì)，你讓我怎么辦，這里面差一個(gè)字段，都不能確認(rèn)具體的客戶的唯一性，而且業(yè)務(wù)也沒有打算給每一個(gè)客戶分配一個(gè)唯一的編碼。

到此即使你拿出軍規(guī)，或者數(shù)據(jù)庫原理來和開發(fā)講，也是無效，他也是受害者?，F(xiàn)在關(guān)鍵的問題是你怎么來化解這個(gè)事情，而不是強(qiáng)硬的創(chuàng)造“對立面”。

解決方法1  和開發(fā)人員商量，是否可以創(chuàng)建遞增主鍵，按照INT 類型，而我們的區(qū)域，客戶類型，以及客戶ID，則作為唯一索引進(jìn)行創(chuàng)建，開發(fā)人員表示可以考慮。

解決方法2  和開發(fā)人員商量，是否可以通過重新物理編碼的方式，通過三個(gè)字段的值進(jìn)行運(yùn)算后得出一個(gè)唯一值，將這個(gè)值作為主鍵，并且計(jì)算值的時(shí)候可以考慮一下順序性例如 

區(qū)域+ 用戶類型 + 用戶ID +數(shù)據(jù)插入時(shí)間 （可以到秒）--根據(jù)輸入的用戶量與時(shí)間的之間的比率。并且在表的字段中加入數(shù)據(jù)插入的時(shí)間，這樣雖然看上去比上面的方式麻煩，但可以解決查詢時(shí)的唯一性，也不需要建立唯一索引，通過主鍵可快速定位相對應(yīng)的用戶。

最后的結(jié)果，開發(fā)選擇了第二種方法，其實(shí)大部分DBA 都是拿出，規(guī)則，規(guī)矩來進(jìn)行限制，當(dāng)然這本身是對的，這也是為系統(tǒng)正常運(yùn)行來考慮的，但如果稍微站在對方的角度，來處理，可能效果預(yù)期會更好。

3 在開發(fā)一個(gè)系統(tǒng)的時(shí)候，大部分開發(fā)人員之前是沒有使用過MYSQL數(shù)據(jù)庫的，在表結(jié)構(gòu)的設(shè)計(jì)，雖然之前提及過的一些MYSQL 特有的規(guī)范，但還是在數(shù)據(jù)庫的設(shè)計(jì)中發(fā)現(xiàn)了大量的主外鍵設(shè)計(jì)，隨即和開發(fā)人員溝通，發(fā)現(xiàn)開發(fā)人員的想法還是在三范式,3NF,以及表之間關(guān)聯(lián)性完整性，以及數(shù)據(jù)的不重復(fù)性考慮。后面和開發(fā)人員溝通，對當(dāng)前使用的MYSQL的版本以及 Join 的MYSQL 操作原理進(jìn)行了講解，開發(fā)人員表示理解，后面和開發(fā)人員將原來的表設(shè)計(jì)重新梳理，將一些頻繁查詢的數(shù)據(jù)匯總到一張表，或兩張表中，不在4-9張表進(jìn)行JOIN 才能獲得數(shù)據(jù)，同時(shí)也對開發(fā)人員在改變設(shè)計(jì)后的繁瑣表示理解。

從溝通中也了解，程序員的想法，大多是根據(jù)3NF的影響，避免不同表中重復(fù)的字段，在查詢中通過多個(gè)表的關(guān)聯(lián)+條件，進(jìn)行信息的輸出，與互聯(lián)網(wǎng)行業(yè)相比某些傳統(tǒng)的行業(yè)的邏輯會比較復(fù)雜，所以使用MYSQL 會讓程序在非數(shù)據(jù)庫層做的更多，想的更多。這也是部分程序員吐槽MYSQL 數(shù)據(jù)庫不好用的原因。

所以和在使用任何一種數(shù)據(jù)庫的時(shí)候，前提要以服務(wù)業(yè)務(wù)為中心，基于所使用的數(shù)據(jù)庫的原理進(jìn)行發(fā)散，或混合行的思維方式，不能只死在一個(gè)數(shù)據(jù)庫，例如如果頻繁的更新狀態(tài)，但一行記錄或業(yè)務(wù)無論有多少次變化，但最后的變化的值是固定的，那是不是可以使用其他的數(shù)據(jù)庫（非RDS）來進(jìn)行快速的狀態(tài)緩沖最終將結(jié)果刷入的到數(shù)據(jù)庫表中，避免由于頻繁更新和查詢產(chǎn)生的性能問題，等等這都是需要開發(fā)和DBA 進(jìn)行溝通，利用互有的知識進(jìn)行，以達(dá)到最大的優(yōu)化和將問題消滅在系統(tǒng)設(shè)計(jì)的初期。

所以，合作能共贏，而軍規(guī)，規(guī)定等等都是一個(gè)范圍，而如果在這個(gè)范圍無法解決問題，則這個(gè)范圍是不是有問題，或者我們是否還能更進(jìn)一步的提高自己的能力，利用各種手段維護(hù)軍規(guī)的同時(shí)，還能滿足業(yè)務(wù)，開發(fā)的需求，這就要看個(gè)人的能力，你會的越多，你解決問題的高度就會更高。相關(guān)與你有關(guān)的對立面就越少。

到此，相信大家對“MYSQL的表設(shè)計(jì)與使用”有了更深的了解，不妨來實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！