作爲程序員，程序設計前的數據庫設計非常重要，這將直接關係到緊接着的代碼編寫工作，這裏談談有關數據庫設計過程中的一些細節問題。
一．數據表主鍵的字段選擇（ID,Code,Number）
ID（編號）一般是選擇GUID，這種格式的字符串是一串全球唯一的字符串。當程序需要調用不同平臺上的相同結構的數據庫時，建議使用guid來作爲主鍵。這樣做的好處是，當在某一平臺上彙總不同平臺的數據時，同一表中的數據彙總不會出現因爲主鍵相同而無法正常彙總的情況。Code（編碼）一般是一串非全數字的字符串，比如字母混合數字格式的字符串。特別是，在設計存在多級關聯關係的對象模型時。比如人員部門結構，商品多級分類等樹狀結構關係的對象模型時（見下圖）。
如上圖所示的部門結構，在數據庫中設置一個部門的編碼Code，結構如圖中加色的數字。這樣做的好處是可以很容易根據這樣的編碼來取到部門的信息。比如，要獲取分局3（0103）下面所屬的所有所一級的人員信息，則可截取表中部門編碼的前四位，判斷其是否等於0103，這樣即可獲得分局3下面所有所一級的部門編碼，再從人員信息表中讀取人員信息就非常簡單了。Number（序號）一般用在標識記錄需要連續計數時，通常是系統自增長生成或者程序自動生成得到。比如某一實物存在多個時，可以使用序號來進行區分。比如圖書館中，一模一樣的圖書存在多本的時候，可以用一個序號來區別。同時，這樣還可以很直觀的看出這個對象有多少個相同的個體記錄，前提是數據未刪除過。設計數據庫的時候可以根據具體的情況加以選擇，從而達到事半功倍的效果。
二．空間換時間的思想
當一張主表和多張從表存在主外鍵關係時，通常的做法是在主表中存取從表記錄的主鍵信息。這樣讀取信息的時候，就需要聯合兩張以及兩張以上的表進行數據讀取和組合得到我們需要的信息。數據庫思想中，有提到數據庫設計應儘可能避免數據冗餘，這樣可以節省數據存儲所佔的空間。但是，在當今社會。硬件技術飛快發展的年代，存儲介質的存儲空間已經可以越來越大，基本不用考慮數據庫佔用的問題。儘管存儲介質的發展很快，但是電腦的處理速度卻難以跟上。所以，設計數據庫的時候，儘可能考慮怎麼使得操作能夠快速響應，以節省用戶等待的時間。這就是空間換時間的思想。比如說，主表中需要存儲用戶表中的用戶姓名，用戶表數據量很大，那麼可以考慮在主表中直接存儲用戶的姓名而不是保存用戶信息記錄的主鍵信息。這樣，只查詢主表即可得到我們需要的信息，而不需要再去聯合用戶表去查詢了。當然，這裏也不是通用的做法，有幾點需要注意。首先這個涉及從表的字段應該是基本上不會再和其他的業務過程產生聯繫的，比如我只需要在查詢的時候顯示這個名字而不需要對其再錯查詢或者修改等其他一系列的業務操作。另外呢，這個數據需要作爲歷史記錄去查閱，那麼就儘可能存儲信息本體而不是信息本體所在表記錄的主鍵了。否則，當從表信息修改之後，再次查詢記錄的時候就會發現與實際情況不符的情況。比如某家公司的快遞寄送人是公司的前臺，但是前臺總會有人事變動，人不在，但是工號還在，會移交給新人使用。那麼記錄寄件人的信息時就直接保存寄件人的姓名。有時候，我們還會選擇將從表的主鍵以及信息主體直接存儲在主表中。比如保存用戶的名字同時存儲用戶的工號。這樣，在檢索的時候就可以根據工號直接得到主表信息，同時得到用戶的工號和姓名。雖然這樣做存在數據冗餘的情況，但是爲了查詢的效率，這樣做未嘗不是一種好辦法。
最後，提一下。數據庫的設計應該以實際情況爲主，理論爲輔，兼顧執行效率。不同情況下，這些做法不一定都適合，具體情況具體分析吧。