今天小編就爲大家分享一篇關於談談數據庫的字段設計的幾個心得，小編覺得內容挺不錯的，現在分享給大家，具有很好的參考價值，需要的朋友一起跟隨小編來看看吧
數據庫的字段設計有很多細節性的技巧，下面將過去在開發中體會到經驗整理出來，做個備忘。
- tinyint 是-128到128 。當屬性設置爲unsigned的時候。最大值就是255了。現在知道爲什麼需要設置爲unsigned屬性了。原來是爲了最大限度的使用給予的存儲空間。如果不設置。那麼假如你的值都是正數的。那麼-128這一百多個數字就相當於是浪費了。
- tinyint會自動設置爲tinyint(3)。
- smallint 不設置unsigned的時候，也有3萬多的樣子。
- tinytext 就是255個字節。大概就是存儲127箇中文的樣子 tinytext就相當於varchar類型。把它看成這樣的該類型就容易理解了。
- int 類型phpmyadmin默認會設置int(10)。
- 概念糾正：原來一直以爲這裏的10表示位數。直到有次想保存1101061021496，結果在字段中的值都變成了：4294967295。 看MySQL手冊上說：
- (int後面括號的數字)顯示寬度並不限制可以在列內保存的值的範圍，也不限制超過列的指定寬度的值的顯示。
- int的範圍：-2147483648到2147483647。剛好是10個位，那麼就是數十億級別的數字。數據庫設計經驗：像訂單的值非常大。不確定，如果達到10位數，還不如使用varchar類型。fangwei就沒有使用int，而是varchar類型。
- 從上面也告訴我一個經驗：如果保存在數據庫的值都變成一樣的。也就是無論我是1101061021496 還是1101061021569，結果都變成了固定的值，比如4294967295。那麼可以考慮確認是否是數據庫該字段的範圍問題。這樣的問題出現過好幾次了。就是沒有掌握思路。導致浪費了不少時間。
- 將字段設置爲not null 還出於另外一種考慮：mysql表的列中包含null的話，那麼該列不會包含在所有中。也就是使用索引是無效的。所有，考慮今後會使用索引的字段，就要設置字段屬性是not null。
- 如果你要保存NULL，手動去設置它，而不是把它設爲默認值。
- 考慮到這個字段今後會作爲查詢關鍵字使用like的形式進行搜索。那麼要將該字段定義成索引。這樣使用like查詢就會更快。
- 現在終於體會到到國外作者書籍上提到：設計數據庫之前要問自己，之後會查詢哪些數據。 考慮了這些，以後有什麼查詢需要。結構都能適應了。
關於設計大流量網站數據庫，會員分表或者分庫的設計考慮：
主鍵不要設爲自增型。設置爲自增型的後果就是：今後無法分離在不同的mysql數據庫服務器上。比如id編號由於是自增的，所以兩個數據庫中可能會出現用戶編號都是10005的情況。
但是，mysql主鍵會自動設置爲自增型。可以用另外一個字段來作爲標識符。而不是自增型id號。方法：新增一個字段作爲行的標識符。具體設計：一個表做兩個字段，一個是id作爲主鍵，自增型，另外一個是uid，作爲用戶的標識。
程序判斷上，是以uid作爲判斷用戶的依據。而不是id主鍵作爲判斷依據(程序上的失誤，改動比起數據庫設計失誤改動容易得多。因爲你數據已經入庫了。在修改起來就比較難了)。
數據庫的一點設計心得
1.按照[流程]順序走一遍 （相關用戶進行一次完成的操作流程）
2.先列出所有的屬性 （實體(型)、 屬性、 聯繫）
3.判斷每一個屬性 是屬於那一個實體
4.實體與實體之間的聯繫 [1:1、 1:n、 n:1、 n:n]
5.相關數據表的設計，允許有數據冗餘（犧牲空間換取效率），但是一定不能有數據項之間的矛盾 [工程與理論之間的考慮]
6.當有多種方式進行數據處理的時候，應該綜合多個方面，進行考慮，選取最適合當前項目的解決方案 [不一定是理論最好的，但卻是適合、實用的]
7.備註: 聯繫的 1：n中， [概念模型]生成[物理模型]的時候， 會把1中的 主鍵作爲，外鍵放入到n中
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對神馬文庫的支持。如果你想了解更多相關內容請查看下面相關鏈接