MYSQL的表設(shè)計與使用

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

當前文章：MYSQL的表設(shè)計與使用
URL網(wǎng)址：http://muchs.cn/article2/jpisic.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供商城網(wǎng)站、自適應(yīng)網(wǎng)站、標簽優(yōu)化、網(wǎng)站制作、ChatGPT、移動網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)