關於未加密密碼欄位的建議
客戶端傳送過來的資料，尤其是密碼都要經過加密處理的，而加密又是一向不可逆的過程，在更改密碼時候，如果傳送到後台php
程式的是加密過的資料，那麼未加密字段
password
就顯得很雞肋。
關於主鍵id
的建議從占用資料庫空間的角度考慮
12位隨機碼占用的資料庫空間為
6個位元組。而用
int欄位型別的話則占用的是
4個位元組
如果我們有10000
條資料的話，那麼
10000x
（6-4
）=20000b=20m
的空間 如果我們有
100萬條資料的話占用的則是
2g的空間。
100萬條資料浪費
2g的容量。
從資料庫優化的角度看
使用者id
是最長在
where
子句中出現的了，資料庫中的查詢是比對方式的，
mysql
將資料乙個乙個的與要查詢的結果字段進行比對，理論上
int欄位型別的資料要比字元型資料快，主鍵
id要建立索引，索引本身也要占用大量的磁碟空間
,每次使用者的變遷都要對索引字段進行修改，有規律的
int比
char
速度要快很多。
從操作方便性的角度看
每次插入id
都要執行生成隨機碼的函式，這本身就不方便，用
primarykey auto
的話這個功能是
c語言封裝好了的，
php的底層是用
c語言寫的，
php是對
c語言的再次封裝，效率要比
c**低好多。
從資料庫安全的角度看
用自動增長型的字段型別，並不會被使用者猜出來，即使猜出來也沒有用，我們的註冊登入並不通過id
只有id
並不能對我們的資料庫造成任何威脅，也不能對我們的後台程式造成任何威脅。真如果能根據咱們的
id就破解我們資料庫**的人，那麼他的技術足可以繞過我們的註冊登入機制，偽造請求對我們的資料庫以及後天程式進行攻擊
綜上考慮我建議id
欄位用primarykey auto_increament
2013 3 27工作中關於資料庫設計的幾點建議
關於未加密密碼欄位的建議 客戶端傳送過來的資料，尤其是密碼都要經過加密處理的，而加密又是一向不可逆的過程，在更改密碼時候，如果傳送到後台php 程式的是加密過的資料，那麼未加密字段 password 就顯得很雞肋。關於主鍵id 的建議從占用資料庫空間的角度考慮 12位隨機碼占用的資料庫空間為 6個位...
工作中資料庫知識使用小結
1.獲取資料庫表的所有欄位的資訊 包括不同列的長度 select from information schema.columns where table name 表名 檢視表結構 desc 表名 2.查詢表中列的注釋資訊 select from information schema.columns...
工作中對資料庫設計的經驗
以下描述僅僅是個人經驗總結，僅供參考！我認為資料庫設計分為庫和表的設計，所以從這兩方面著手介紹。庫的設計 1 資料庫名稱要明確，可以加字首或字尾的方式，使其看起來有業務含義，比如資料庫名稱可以為business db 業務資料庫 2 在乙個企業中，如果依賴很多產品，但是每個產品都使用同一套使用者，那...