每個表都應該有壹個ID列，任何兩條記錄都不能* * *共享同壹個ID值。
另外，最好有壹個數據庫來自動管理這個ID值，而不是把這個任務交給前臺應用。
否則，很容易造成ID值不統壹。
另外，在設計數據庫的時候，最好加上行號。
例如，在銷售訂單管理中，用戶不能維護ID號。
但是，行號用戶可以維護
例如，在銷售訂單行中，用戶可以通過調整行號的大小來對訂單行進行排序。
通常，ID列以1為單位遞增。
但是，行號應該以10為單位遞增。
這樣壹般情況下，線號會按照10，20，30的順序進行擴展。
如果用戶此時需要將行號為30的記錄轉移到第壹行顯示。
此時，用戶如果不能更改ID列，可以更改行號。
如果能把行號改為1，排序時就可以按行號排序。
在這種情況下，原來行號為30的記錄現在是1，因此可以顯示在第壹行。
這是實際應用設計中對ID列的有效補充。
這些內容是課本上沒有的。
妳需要在實際的應用設計中掌握這個技巧。
四:數據庫對象應該有壹個統壹的前綴名。壹個相對復雜的應用系統通常有數千個相應的數據庫表。
數據庫管理員看到這個數據庫對象的名字恐怕很難理解它的功能。
而且在引用數據庫對象時，數據庫管理員也會為不能快速找到所需的數據庫對象而頭疼。
因此，作者認為，在開發數據庫之前，最好花壹些時間為數據庫對象制定壹個前綴命名規範。
比如設計數據庫的時候，我喜歡和前臺應用協商確定壹個合理的命名標準。
作者通常根據前臺應用程序的模塊來定義後臺數據庫對象的前綴名。
例如，與物料管理模塊相關的表可以以m為前綴；對於與訂單管理相關的，可以使用C作為前綴。
可以根據用戶的偏好來定義使用什麽前綴。
但是需要註意的是，這個命名約定要在數據庫管理員和前臺應用開發者之間達成理解，對象名要嚴格按照這個命名約定來定義。
其次是表、視圖、函數等。也應該有統壹的前綴。
例如，視圖可以以V為前綴，而函數可以以f為前綴。
這樣無論是日常管理還是對象引用，數據庫管理員都能在最短的時間內找到自己需要的對象。
五:盡量只存儲單壹實體類型的數據。這裏的實體類型和數據類型不壹樣，要註意區分。
這裏所說的實體類型是指需要描述的對象本身。
筆者舉個例子，估計大家都能看懂內容。
比如現在圖書館有壹個系統，有兩個實體對象:圖書基本信息和作者信息。
用戶也可以將這兩個實體的信息放在同壹個表中。
比如表格可以設計成書名、書作者等等。
但是這樣的設計會給後續的維護帶來很多麻煩。
如果有後續的書出版，就需要為每本出版的書添加作者信息，這無疑會增加額外的存儲空間，增加記錄的長度。
而如果作者的情況發生了變化，比如地址發生了變化，就需要更改每本書的記錄。
如果把這個作者的書全部從數據庫裏刪除，這個作者的信息就沒了。
顯然，這不符合數據庫設計標準化的要求。
在這種情況下，作者建議可以將上面的表分解成三個獨立的表，即圖書基本信息表、作者基本信息表、圖書與作者對應表等等。
經過這樣的設計，上面遇到的問題都將迎刃而解。