一、【操作規范】
1. 如無備注，則表中的第一個id字段一定是主鍵且為自動增長；
2. 如無備注，則數值類型的字段請使用UNSIGNED屬性；
3. 如無備注，排序字段order_id在程序中默認使用降序排列；
4. 如無備注，所有字段都設置NOT NULL，並設置默認值；
5. 如無備注，所有的布爾值字段，如is_hot、is_deleted，都必須設置一個默認值，並設為0；
6. 所有的數字類型字段，都必須設置一個默認值，並設為0；
7. 針對varchar類型字段的程序處理，請驗證用戶輸入，不要超出其預設的長度；
8. 建表時將數據字典中的字段中文名和屬性備注寫入數據表的備注中(“PK、自動增長”不用寫)；
9. 如無說明，建表時一律采用innodb引擎；
二、【常用表名約定】
0. 說明：表前綴用項目名稱首字母縮寫；所以表名都小寫，單詞之間用下划線分開，單詞都用單數形式
1. user – 用戶
2. category – 分類
3. goods – 商品、產品等一切可交易網站的物品都用此命名
4. good_gallery – 物品的相冊
5. good_cate – 物品的分類，除了單獨作為表名，其他地方分類單詞一律用縮寫cate
4. attr – 屬性
5. article – 文章、新聞、幫助中心等以文章形式出現的，一般都用此命名
6. cart – 購物車
7. feedback – 用戶反饋
8. order – 訂單
9. site_nav – 包括頁頭和頁尾導航
10. site_config – 系統配置表
11. admin – 后台用戶 【RBAC標准表】
12. role – 后台用戶角色【RBAC標准表】
13. access – 后台操作權限，相當於action【RBAC標准表】
14. role_admin – 后台用戶對應的角色【RBAC標准表】
15. access_role – 后台角色對應的權限【RBAC標准表】
16. 待續
三、【常用列名約定】
1. 表名_id – 通常用作外鍵命名
2. cid – 特殊的編號，帶有元數據，方便關聯查詢，你可以把它理解成類別(層次)編號。舉個例子，產品在分類時，往往需要將其歸類到子分類下，相應的字段中也一般只記錄子分類的id，這時若需要知道該產品屬於哪個主分類，就需要通過子分類信息再查詢到主分類信息，這是比較麻煩的，cid字段就是要解決這個問題。一般的站點幾十個分類肯定是夠用了，所以這里假設某一主分類的cid為11，則子分類的cid從1101開始編號，處理時只需截取前兩位數值便可知道該產品屬於哪一個主分類了。
3. add_time – 添加時間、上架時間等
4. last_time – 最后操作時間，如登錄、修改記錄
5. expire_time – 過期時間
6. name – 商品名稱、商家名稱等，不要跟title混用，title只用於文章標題、職稱等
7. price – 價格
8. thumb – 只要是列表頁面中的窗口圖，一律用此命名
9. image_src – 相冊中的圖片地址一律用此命名，不要出現各種img,image,img_url,thumb_url等
10. head_thumb – 用戶頭像， 雖然有點長，一定要遵守。不要出現上述情況
11. image_alt – 相冊中圖片的alt屬性
12. desc – 描述、簡介，比如goods_desc，不要出現goods_txt這種
13. details – 詳情、文章內容等
14. order_id – 排序
15. telephone – 座機號碼
16. mobile – 手機號碼
17. phone – 當不區分手機和座機時，請用phone命名
18. address – 地址，單獨出現不要用addr縮寫，組合出現時需用縮寫，比如mac地址，mac_addr
19. zipcode – 郵編
20. region – 地區，大的區域，比如記錄杭州市、溫州市等
21. area – 區域，小的，比如上城區，江干區等
22. avg_cost – 人均消費
23. 待續
四、【數據表字段設計范例】
分類表（t_category）
| 字段名 |
列名 |
類型 |
屬性備注
|
|
| 流水號 |
id |
int(10) |
PK、自動增長 |
|
| 特殊編號 |
cid |
varchar(4) |
第一個主分類為11、第一個子分類為1101，類推，僅支持二級分類 |
|
| 名稱 |
name |
varchar(10) |
頁面中需注明輸入不超過10個字 |
|
| 父分類 |
pid |
int(10) |
||
| 統計量 |
count |
int(10) |
||
| 是否熱門 |
is_hot |
tinyint(1) |
||
| 首頁顯示 |
is_index |
tinyint(1) |
||
| 排序 |
order_id |
int(10) |
|
|
[表命名規范]
1.具備統一前綴，對相關功能的表應當使用相同前綴，如acl_xxx，house_xxx,ppc_xxx；其中前綴通常為這個表的模塊或依賴主實體對象的名字，通常來講表名為：業務_動作_類型，或是業務_類型；
2.表名使用英文小寫單詞，如果有多個單詞則使用下划線隔開；
3.表名簡介，使用常見單詞，避免使用長單詞和生僻詞；
4.表引擎取決於實際應用場景及當前數據庫中的已經存在的存儲引擎；日志及報表類表建議用myisam，與交易，審核，金額相關的表建議用innodb引擎。總體來講數據庫默認innodb；
5.數據表必須有主鍵，且建議均使用auto_increment的id作為主鍵（與業務無關）,和業務相關的要做為唯一索引；
6.默認使用utf8字符集（由於數據庫定義使用了默認，數據表可以不再定義，但為保險起見，建議都寫上）；
7.所有的表都必須有備注，寫明白這個表中存放的數據內容；
8.預估表數據量，如果數據量較大（超過500w）則需要考慮分表策略。可以等量均衡分表或根據業務規則分表均可。要分表的數據表必須與DBA商量分表策略；
9.職責相近的表，命名規則應該相同；如合同申請，賬戶信息，交友相關等；
舉個例子，一張在線沖值記錄表：user_bank_deposit這個就非常符合標准，如果叫做userBankDeposit或是user_chongzhi，就非常不友好。
CREATE TABLE `house_refresh_log` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增ID',
`fangid` int(11) NOT NULL COMMENT '房貼子ID',
`refresh_time` int(11) NOT NULL COMMENT '刷新時間',
PRIMARY KEY (`id`),
UNIQUE KEY `fangid` (`fangid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='房刷新記錄表'
[字段命名規范]
1.數據庫字段命名與表名命名類似：
2.使用小寫英文單詞，如果有多個單詞使用下划線隔開；
3.使用簡單單詞，避免生僻詞；
4.字段應當有注釋，描述該字段的用途及可能存儲的內容，如枚舉值則建議將該字段中使用的內容都定義出來；
5.是別的表的外鍵均使用xxx_id的方式來表明；
6.表的主鍵一般都約定成為id，自增類型；
7.時間字段，除特殊情況一律采用int來記錄unix_timestamp；
8.網絡IP字段，除特殊情況一律用bigint來記錄inet_aton值；
9.所有字段，均為非空，最好顯示指定默認值；
10.有些驅動對tinyint支持不夠好，通常建義按容量來選擇字段；
11. text字段盡量少用，或是拆到冗余表中；
CREATE TABLE `wanted_post` (
`id` int(10) NOT NULL AUTO_INCREMENT,
`puid` int(10) unsigned NOT NULL,
`user_id` int(10) NOT NULL COMMENT '發貼用戶的id',
`username` varchar(50) NOT NULL COMMENT '發貼用戶的用戶名',
`city` smallint(4) NOT NULL COMMENT '所在城市',
`ip` bigint(14) NOT NULL COMMENT '發帖人的ip',
`district_id` tinyint(2) NOT NULL COMMENT '所在區域的id',
`district_name` varchar(20) NOT NULL COMMENT '行政區名字',
`street_id` tinyint(2) NOT NULL COMMENT '所在街道(地標)的id',
`street_name` varchar(20) NOT NULL COMMENT '小區名字',
`title` varchar(255) NOT NULL COMMENT '帖子的標題',
`description` text NOT NULL COMMENT '帖子詳情描述',
`post_at` int(11) NOT NULL COMMENT '用戶發帖時間,數據創建的時間,使用整型存儲',
`refresh_at` int(11) NOT NULL COMMENT '帖子被修改的時間,整型存儲',
`show_time` int(11) NOT NULL COMMENT '帖子顯示時間',
`age_max` int(11) NOT NULL DEFAULT '0' COMMENT '招聘最小年齡',
`age_min` int(11) NOT NULL DEFAULT '0' COMMENT '招聘最大年齡',
`post_refresh_at` int(11) NOT NULL COMMENT '刷新時間',
PRIMARY KEY (`id`),
UNIQUE KEY `idx_puid` (`puid`),
KEY `user_id_index` (`user_id`),
KEY `post_at_index` (`post_at`),
KEY `refresh_at_index` (`refresh_at`),
KEY `show_time_index` (`show_time`)
) ENGINE=InnoDB AUTO_INCREMENT=55295 DEFAULT CHARSET=utf8 COMMENT='招聘帖子表'
http://blog.csdn.net/yuzhouxiang/article/details/7088352
數據庫設計表及字段命名規范(我整理的，望大家多多提建議)
1.數據庫表命名規范:
(1)表名前應該加上前綴，表的前綴一個用系統或模塊的英文名稱縮寫，前綴全部大寫或首字母大寫，表名中包含的單詞首字母大寫。
(2)數據庫表名應該有意義，並且易於理解，最好使用可以表達功能的英文單詞或縮寫，如果用英文單詞表示，建議使用完整的英文單詞。
(3)表名不可以太長，最好不要超過3個英文單詞長度（22個字母）。
(4)在數據庫表命名時應該用英文單詞的單數形式，如員工表命名：應該為Employee而不是Employees.
(5)如果是后台表命名時應該在表名基礎上加上后綴
_b
(back 首字母 )
(6)在表創建完成前，應該為表添加表的注釋。
2.表字段命名規范：
(1)數據庫表字段應該是有意義而且易於理解的，最好是能夠表達字段含義的英文字母
（有人認為如果用英文單詞作為字段，因為翻譯工具不同，而字段不統一建議使用漢語拼音首字母縮寫
；有人認為用漢語拼音縮寫看起來不直觀，老半天也不知道到底這個字段是干什么的）
(2)系統中所有屬於內碼，即僅用於標識唯一性和程序內部用到的標識性字段，字段名稱建議取為 ID ，采用類型為整型或長整型.
(3)系統中屬於是業務內的編號字段，代表一定業務信息，建議字段命名為
code , 如工作單編號
wf_code .
(4) 不要在數據庫表字段（列名）中包含數據類型，如：datetime
(5)不要在數據庫表字段（列名）命名時重復表名，可以使用表名首字母（不包含數據庫表名前綴）
注意：
不要在數據庫表字段（列名）命名時
不建議使用數據庫關鍵字,如：name,time,datetime password 等
3.表設計規范：
(1)所有字段在設計時，除以下數據類型timestamp、image、datetime、smalldatetime、uniqueidentifier、binary、sql_variant、binary、varbinary外，必須有默認值。字符型的默認值為一個空字符值串’’；數值型的默認值為數值0；邏輯型的默認值為數值0；
其中：系統中所有邏輯型中數值0表示為“假”；數值1表示為“真”。
datetime、smalldatetime類型的字段沒有默認值，必須為NULL。
(2)當字段定義為字符串形時建議使用varchar而不用nvarchar。
注
：在MySQL5.0以上的版本中，varchar數據類型的長度支持到了65535，也就是說可以存放65532個字節的數據，起始位和結束位占去了3個
字節。
(3)建議在大多數表中（如工作單），應都有以下字段：
字段名說明類型默認值
CreatorID創建者int
默認值為
0
CreatedTime創建時間Datetime
默認值為NULL
(4)字段的描述
a.字段必須填寫描述信息（注釋）
b.盡量遵守第三范式的標准（3NF）
表內的每一個值只能被表達一次（列名不重復）
表內的每一行都應當被唯一的標示（標識唯一性，如
自動增長
主鍵）
表內不應該存儲依賴於其他鍵的非鍵信息
(5)加索引規則
a.表建好后數據庫自動為表生成一個索引（為
自動增長的列生成唯一索引），如果在對這列添加索引，數據庫會給一個警告,內容大概是，已經為這列添加了索引，建議修改索引名稱和自動增長列名保持一致，為了方便使用。
b.如果在添加索引時，建議索引名稱和數據庫列名保持一致，為了方便使用
c.如果字段事實上是與其它表的關鍵字相關聯而未設計為外鍵引用，需建索引。
d.如果字段與其它表的字段相關聯，需建索引。
e.如果字段需做模糊查詢之外的條件查詢，需建索引。
f.除了主關鍵字允許建立簇索引外，其它字段所建索引必須為非簇索引。
4.存儲過程命名規范
(1)
存貯過程的命名請遵循以下命名規范：USP_+ 系統模塊縮寫（與表前綴類似）+_+ 功能標識 + 代表存貯過程操作的主要表名（不帶前綴）或功能的英文單詞或英文單詞縮寫。
如果一個存貯過程只對一個表進行操作，建議存貯過程的名稱就用存貯過程所操作的表的表名（不帶前綴）。這樣有利於根據表名找到相應的存貯過程。例如：
用於新增的存貯過程USP_MESSAGE_Add_Model
用於修改的存貯過程USP_ MESSAGE_Upt_Model
用於刪除的存貯過程USP_ MESSAGE_Del_ Modele
注：USP是user storedprocedure
縮寫
5.存儲過程設計規范
在存貯過程中必須說明以下內容：
(1)目的：說明此存貯過程的作用。
(2)作者：首次創建此存貯過程的人的姓名。在此請使用中文全名，不允許使用英文簡稱。
(3)創建日期：創建存貯過程時的日期。
(4)修改記錄：
修改記錄需包含修改順序號、修改者、修改日期、修改原因，修改時不能直接在原來的代碼上修改，也不能刪除原來的代碼，只能先將原來的代碼注釋掉，再重新增加正確的代碼。修改順序號的形式為：log1，log2，log3。。。，根據修改次數順序增加，同時在注釋掉的原來的代碼塊和新增的正確代碼塊前后注明修改順序號。
(5)對存貯過程各參數及變量的中文注解。
建議：在數據庫中創建一個文本文件保存創建腳本
6.視圖命名規范
視圖的命名請遵循以下命名規范：UV _ + 系統模塊縮寫（與表前綴類似）+_+ 功能標識 + 代表視圖查詢的主要表名（不帶前綴）或功能的英文單詞或英文單詞縮寫。
如果一個視圖只對一個表進行查詢，建議視圖的名稱就用視圖所查詢的表的表名（不帶前綴）。這樣有利於根據表名找到相應的視圖。
注：UV是userView縮寫
7.視圖設計規范
在視圖中必須說明以下內容：
(1)目的：說明此視圖的作用。
(2)創建者：首次創建此視圖的人的姓名。在此請使用中文全名，不允許使用英文簡稱。
(3)修改者、修改日期、修改原因：如果有人對此視圖進行了修改，則必須在此視圖的前面加注修改者姓名、修改日期及修改原因。
(4)對視圖各參數及變量的中文注解
建議：在數據庫中創建一個文本文件保存創建腳本
8.觸發器命名規范
Insert觸發器加'_i'，Delete觸發器加'_d'，Update觸發器加'_u'
9.觸發器設計規范
在視圖中必須說明以下內容：
(1)目的：說明此觸發器的作用。
(2)創建者：首次創建此觸發器的人的姓名。在此請使用中文全名，不允許使用英文簡稱。
(3)修改者、修改日期、修改原因：如果有人對此觸發器進行了修改，則必須在此觸發器的前面加注修改者姓名、修改日期及修改原因。
(4)對觸發器各參數及變量的中文注解
建議：在數據庫中創建一個文本文件保存創建腳本