資料庫的設計必須符合三個正規化（極端要求常用高速時考慮單獨設定記錄表除外）。
用整形代替浮點型float，decimal等，有的語言浮點計算是不精準的，如int存最小單位。
金額用分， 重量用克等
//**分
public function getpricefen($pricefen)
資料表的字段應避免使用varchar、 text等不定長的型別，時間資訊的字段使用unixtiemstamp型別儲存。查詢資料時禁止使用*萬用字元避免占用資源加速處理速度，盡量避免使用臨時表。查詢資料連線多表時各資源應該使用全名稱，即tablename.fieldname，而不是fieldname。sql語句應盡可能符合ansi92標準，避免使用特定資料庫對 sql語言的擴充特性。開發結束後，必須針對sql查詢語句的條件語句部分（where）新增索引，須匹配多個條件的應該使用聚合索引。索引的組成應由左至右匹配條件語句的順序。
嚴禁盲目新增索引，避免減慢資料插入的速度、增大占用空間及減慢查詢速度。
每當資料庫（表）發生結構性變化時須登記儲存；日常須定時（不超過三個工作日）
備份資料庫結構及其資料。
用filed='x'不要用filed="x"在mysql中，使用單引號和雙引號倆種表達方法是一樣的，儘管使用單引號的表達方法符合ansi-sql/92標準。當修改了mysql的sql模式的時候（set @@global.sql_mode）的時候，選擇不同sql模式，可能會出現單引號和雙引號的區別。用的雙引號，sql語句執行錯誤.可以看出，盡量還是使用單引號
資料庫的字段設計有很多細節性的技巧，下面將過去在開發中體會到經驗整理出來，做個備忘。
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主鍵作為判斷依據(程式上的失誤，改動比起資料庫設計失誤改動容易得多。因為你資料已經入庫了。在修改起來就比較難了)。
資料庫設計經驗談 下
資料庫設計經驗談 下 第 3 部分 選擇鍵和索引 資料採掘要預先計畫 我所在的某一客戶部門一度要處理 8 萬多份 同時填寫每個客戶的必要資料 這絕對不是小活 我從中還要確定出一組客戶作為市場目標。當我從最開始設計表和字段的時候，我試圖不在主索引裡增加太多的字段以便加快資料庫的執行速度。然後我意識到特...
資料庫設計經驗談 下
引用 http blog.csdn.net softj services trackbacks 497813.aspx 第 3 部分 選擇鍵和索引 資料採掘要預先計畫 我所在的某一客戶部門一度要處理 8 萬多份 同時填寫每個客戶的必要資料 這絕對不是小活 我從中還要確定出一組客戶作為市場目標。當我從...
資料庫設計經驗談 4
第 4 部分 保證資料的完整性 如果你按照商務規則來處理需求，那麼你應當檢查商務層次 使用者介面 如果商務規則以後發生變化，那麼只需要進行更新即可。假如需求源於維護資料完整性的需要，那麼在資料庫層面上需要施加限制條件。如果你在資料層確實採用了約束，你要保證有辦法把更新不能通過約束檢查的原因採用使用者...