資料庫表的命名規範

2021-12-30 13:09:45 字數 3693 閱讀 7340

1.表名一般以【模組名稱_具體表名】來實現,同乙個模組的字首是一樣的。(oracle大小寫敏感,在sql中可以不用"_",因為可以用大小寫一起的寫法。這也是可以的)

2.表名稱不應該取得太長(一般不超過三個英文單詞,不推薦使用中文拼音,總的長度不要超過30個字元)。表名使用英文的原因,有些專案有英文版的需要,或者這個專案是給外國做的時候,使用英文是基本的要求,應該說這是乙個習慣問題,多學一點英文也不是壞事 3.不使用tab或tb作為表字首(本來就是乙個表,為什麼還要說明)。 4.一些作為多對多連線的表,可以使用兩個表的字首作為表名:如:使用者登入表user_login,使用者分組表user_groupinfo,這兩個表建立多對多關係的表名為:user_group_relation(關係統一用relation)。注意一點,主鍵在做其他表的外來鍵時,或者在被其他表引用時,字段說明和欄位名盡量保持一致,比如發帖表bbs_topic裡的使用者字段寫成ui_id,這樣跟使用者資訊表user_info的主鍵ui_id保持一致,看起來舒服,對應關係很明確,也不容易錯,前後不一致時容易令人費解。 5.當系統中有一些少量的,重複出現的值時,使用字典表來節約儲存空間和優化查詢。如地區、系統中使用者型別的代號等。這類值不會在程式的執行期變化,但是需要儲存在資料庫中。一般資料庫中,都有乙個資料字典表,用來儲存系統所用到的基礎資料,大型的字段表如省份城市區域的字典表,統一以dictionary_作為字首。 6. 與字段有關,預設的一些特殊字段, 很多表中,  比如一些業務處理表中,除了新增生成的自動編號id(一般作為主鍵用),該記錄建立的時間createdate(建立時間),該記錄的建立人creatby(注意這裡,沒ui_id(使用者資訊表user_info的主鍵ui_id),因為還有修改人),最後修改人lasteditby,最後修改時間lasteditdate。(這些可以直接使用中文字元,而不使用編碼,提高查詢的效率)  同時有的時候需要注意,刪除的時候並不真的刪除該記錄,而是新增乙個標識位,比如xx_deletestaus刪除狀態。1是有效的,0則是無效的。 7.在命名表時,用單數形式表示名稱。例如,使用 employee,而不是 employees。 8.資料庫中應建立這樣乙個表,就是資料庫本身的字段資訊,表的說明,也就是資料庫設計文件的乙個表,方便查詢使用,有什麼不明的可以直接從資料庫查詢,資料庫文件丟失,注釋丟失,都可以重新起作用。 9.每個表都應該有乙個主鍵,這個主鍵最好是數字,而且是遞增的,有很多表的主鍵用32位字元編碼,這樣做的目的更多的是從安全考慮的。因為字元多時索引時效率低,而使用自增列也不是很少,比如新增主表和從表操作時,主表的主鍵是從表的外來鍵,這個時候還有取返回值,然後再新增,不可以同時新增。主鍵可以用自定義的規則,大部分用max(id)的做法,也可以自定義乙個序列表,有點像序列,或者用時間的年月日秒具體到毫秒。關於列的命名,建議對資料型別也做一些規範,因為很容易確定,只有四種主要型別:數字,字元,時間,邏輯值,這些在型別上和長度上都可以定好規範,統一起來。 10.操作日誌表,登入日誌表,這是資料庫中必備的兩個表,這個記錄也需要做進一步的儲存。這個有兩種情形,一是具體到單個欄位的操作日誌,二是整個表的操作日誌。

常見的幾個表具體說明:操作日誌表sys_operatelog、登入日誌表sys_loginlog、

系統字典表sys_dictionary、系統字典表型別sys_dictype

操作日誌表sys_operatelog

中文名欄位名

注釋 操作日誌編號

ol_id

索引列,日誌的編號

操作型別

ol_type

是新增,修改,刪除,查詢等類容(可放在通用字典表)

操作模組

ol_module

操作模組,比如新聞模組,關聯的是選單表編號

操作內容

ol_content

操作了什麼內容,越具體越好(修改前、修改後)

操作人ui_id

使用者的資訊

操作時間

ol_adddate

日誌記錄建立時間

操作ip

ol_ip

操作人的ip位址

備註資訊

ol_remarks

備註資訊,一些其他的需要說明的資訊

這樣的乙個操作日誌比較籠統,不是能具體到具體的字段值更新,如果要具體到某個具體值的更新,則需要設計新的資料庫

一般情況下需要這樣幾個表,系統中可能已經有了,但是我們拿到我們自己的資料庫中來,乙個是資料庫列表的表(就是資料庫中有幾個表)(編號,建立時間,建立人,修改時間,修改人,表名,注釋,是否刪除),然後就是資料庫表下面的字段型別(編號,建立時間,建立人,修改時間,修改人,欄位名,字段型別,字段精度,字段說明,字段注釋,表的編號),也就是字段列表,這時的日誌操作表可以這樣設計(編號,表名,被修改的欄位名,修改前值,修改後值,操作人,操作時間,相關模組,操作ip) 這種能記錄修改記錄,但是新增和刪除時記錄就不是很方便控制了。 

登入日誌表sys_loginlog

中文名欄位名

注釋 登入日誌編號

ll_id

登入的日誌編號

登入人ui_id

登入人

登入時間

ll_adddate

登入時間

登入ip

ll_ip

登入的ip位址

登入狀態

ll_status

登入是否成功的標識位

登入瀏覽器

ll_browser

登入瀏覽器

登入解析度

ll_resolution

登入的螢幕解析度

還有乙個就是資料字典表,我看過很多的資料庫設計,型別表乙個接乙個,沒有放在一起,還有的乾脆寫在注釋裡,有的根本就沒有,這樣某個程式設計師走了,這個欄位就沒人知道了,即使沒走,自己也有可能時間長了忘掉,所以,見乙個基礎資料字典表的作用非常重要,其他的比如地區表(sys_dicarea),漢語拼音表(sys_diccharacter)(用來漢字和拼音的轉換)因為資料量較大,單獨建表。這裡介紹通用的資料字典表。

系統字典表sys_dictionary

中文名欄位名

注釋 字典編號

sd_id

字典的編號,可以直接使用此主鍵編碼(注意刪除時的關聯關係)

字典型別

dy_id

字典型別的id,需要建立字典型別表,因為放的是所有的字典表

字典編碼

sd_code

字典編碼,支援自己編碼(同一型別是唯一的,一般是整數型

字典中文名稱

sd_name

字典中文名稱(比如男女,比如狀態,可以放在字典表裡,作為檢視依據)

字典備註

sd_remarks

字典備註,字典需要一些備註資訊

建立人建立日期

修改人修改日期

系統字典表型別sys_dictype

中文名欄位名

注釋 字典型別編號

dt_id

字典的自動索引號

字典型別名稱

dt_name

字典型別的中文名稱

字典的備註說明

dt_remarks

字典使用的備註說明

字典狀態

dt_status

字典是否刪除,不在使用

最後補充一些內容,一般設計資料庫是這個樣子的,但是不排除有些特殊的情形,為了資料的保密性,資料庫的表名和欄位名都是一些看似毫無意義的字元數字,比如table1,col1,但是有乙個表是說明表,或者有對應的資料庫文件設計。

補充:一些列說明了單位型別,可以在設計資料庫的時候表明,比如heightincm, weightinkg.這樣一目了然。

資料庫表的命名規範

資料檔案命名採用系統名 檔案型別,比如系統名為kupage,則資料庫檔案命名為kupage database.mdf,有的資料庫檔案有多個,比如sql server就有2個,乙個是資料庫檔案,另乙個是日誌檔案,那麼他們的檔案命名分別為 kupage database.mdf,kupage log.l...

mysql的庫命名規範 資料庫命名規範(命名規則)

資料庫命名規範 引言 資料庫設計過程中庫 表 欄位等的命名規範也算是設計規範的一部分,不過設計規範更多的是為了確保資料庫設計的合理性 為了專案最終的協調穩定性,而命名規範更多的是為了確保設計的正式和統一。資料庫中欄位等等以什麼樣的命名方式,並不會直接影響到專案的穩定性。制定規範的直接目的是約束行為,...

資料庫命名規範

1 目的 規範資料庫各種物件的命名規則。2 資料庫命名原則 2.1 資料檔案 如果資料庫採用檔案系統,而不是裸裝置,約定下列命名規則 1 資料檔案以表空間名為開始,以.dbf為結尾,全部採用小寫英文本母加數字命名。如該表空間有多個資料檔案,則從第2個資料檔案開始,在表空間名後加 例 對system表...