小心保留詞
要保證你的字段名沒有和保留詞、數據庫系統或者常用訪問方法沖突，比如，最近我編寫的一個 ODBC 連接程序里有個表，其中就用了 DESC 作為說明字段名。后果可想而知！DESC 是 DESCENDING 縮寫后的保留詞。表里的一個 SELECT * 語句倒是能用，但我得到的卻是一大堆毫無用處的信息。
保持字段名和類型的一致性
在命名字段并為其指定數據類型的時候一定要保證一致性。假如字段在某個表中叫做“agreement_number”，你就別在另一個表里把名字改成“ref1”。假如數據類型在一個表里是整數，那在另一個表里可就別變成字符型了。記住，你干完自己的活了，其他人還要用你的數據庫呢。
仔細選擇數字類型
在 SQL 中使用 smallint 和 tinyint 類型要特別小心，比如，假如你想看看月銷售總額，你的總額字段類型是 smallint，那么，如果總額超過了 $32,767 你就不能進行計算操作了。
刪除標記
在表中包含一個“刪除標記”字段，這樣就可以把行標記為刪除。在關系數據庫里不要單獨刪除某一行；最好采用清除數據程序而且要仔細維護索引整體性。
避免使用觸發器
觸發器的功能通?？梢杂闷渌绞綄崿F。在調試程序時觸發器可能成為干擾。假如你確實需要采用觸發器，你最好集中對它文檔化。
包含版本機制
建議你在數據庫中引入版本控制機制來確定使用中的數據庫的版本。無論如何你都要實現這一要求。時間一長，用戶的需求總是會改變的。最終可能會要求修改數據庫結構。雖然你可以通過檢查新字段或者索引來確定數據庫結構的版本，但我發現把版本信息直接存放到數據庫中不更為方便嗎？
給文本字段留足余量
ID 類型的文本字段，比如客戶 ID 或定單號等等都應該設置得比一般想象更大，因為時間不長你多半就會因為要添加額外的字符而難堪不已。比方說，假設你的客戶 ID 為 10 位數長。那你應該把數據庫表字段的長度設為 12 或者 13 個字符長。這算浪費空間嗎？是有一點，但也沒你想象的那么多：一個字段加長 3 個字符在有 1 百萬條記錄，再加上一點索引的情況下才不過讓整個數據庫多占據 3MB 的空間。但這額外占據的空間卻無需將來重構整個數據庫就可以實現數據庫規模的增長了。身份證的號碼從 15 位變成 18 位就是最好和最慘痛的例子。
列[字段]命名技巧
我們發現，假如你給每個表的列[字段]名都采用統一的前綴，那么在編寫 SQL 表達式的時候會得到大大的簡化。這樣做也確實有缺點，比如破壞了自動表連接工具的作用，后者把公共列[字段]名同某些數據庫聯系起來，不過就連這些工具有時不也連接錯誤嘛。舉個簡單的例子，假設有兩個表：
Customer 和 Order。Customer 表的前綴是 cu_，所以該表內的子段名如下：cu_name_id、cu_surname、cu_initials 和cu_address 等。Order 表的前綴是 or_，所以子段名是：or_order_id、or_cust_name_id、or_quantity 和 or_description 等。
這樣從數據庫中選出全部數據的 SQL 語句可以寫成如下所示：
Select * From Customer, Order Where cu_surname = "MYNAME" ;
and cu_name_id = or_cust_name_id and or_quantity = 1
在沒有這些前綴的情況下則寫成這個樣子（用別名來區分）：
Select * From Customer, Order Where Customer.surname = "MYNAME" ;
and Customer.name_id = Order.cust_name_id and Order.quantity = 1
第 1 個 SQL 語句沒少鍵入多少字符。但如果查詢涉及到 5 個表乃至更多的列[字段]你就知道這個技巧多有用了。
預告：第 3 部分 - 選擇鍵
怎么選擇鍵呢？這里有 10 個技巧專門涉及系統生成的主鍵的正確用法，還有何 時以及如何索引字段以獲得最佳性能等。