因項目而已，純屬個人總結記錄：
1、建立外鍵關係：通過外鍵關係，保持數據一致性及更新同步性。比如，目前數據庫存在涉及到引用另一數據表的信息，直接在本表重複建數據庫字段（或ID串），在查詢時表面看來似乎減少了表連接所用的時效，但如此卻很難保持數據統一，比如被引用數據發生改變時，引用起數據表中仍爲原信息，且造成數據冗餘。
2、涉及到表之間有關聯關係的，應建立外鍵約束，以保持數據同步更新。如表1中用到表2中僅“名稱”一個字段，也應建立外鍵關係，而非只是把表2中名稱值放入表1，儘管這樣sql少了一層關聯，但效率提高效果上並不明顯。
3、對於數據庫設計文檔要保存數據庫物理模型圖，只保存數據庫中麼個表的結構（字段）信息，很難高效掌握數據庫表之間的邏輯關係，因而在實現業務時也很難直接得到執行的業務sql。
4、對於數據庫訪問層，常用的訪問sql規範化，方法中固定了sql的結構及拼接方式，只需在方法參數中傳入構成sql需要的參數，如此可以簡化代碼，而且可以使每個操作數據庫人員執行的sql寫法相同，也可以保證sql效率達到目前最優，日後一旦發現更好的sql，可以只修改方法中sql的拼接及定義方式。
5、對於數據訪問層，不同的方法，涉及到對數據庫做相同交互的要封裝出一個公用的方法，以便維護。如將DataTable數據轉換爲Model方法、根據條件到數據庫中查詢DataTable數據集方法等，封裝好後，其他方法只需調用封裝好的方法，將數據做處理。
6、（參考）對於獲取全部數據的情況，如查詢數據表全部內容，獲取數據實體Model等情況，業務上爲查詢數據表全部列，則可以使用select * 而不是select 字段1， 字段2...，因爲當數據表增加字段時，第二種方式需要依次修改，不便維護。
7、適當使用存儲過程，比如分頁方法。也許存儲過程（在數據庫中建臨時表）實現方案效率更高。
8、對於Model類中字段類型的定義，可均採用string類型，因爲string類型很容易實現轉換爲其他類型，使用靈活。如此可以統一DAL層中add及update方法，拼接sql過程中，對每個字段判斷是否爲null，不爲null才拼入sql中。均設爲string的優點是，一些特殊類型，如整形爲空，時間類型等等，通過字符串處理轉換比較簡單，但也有個缺點，就是在數據庫訪問層拼接sql時，要清楚哪個字段需要做如何的類型轉換，比如時間類型，sqlserver中需要cast轉換，oracle需要to_date，postgresql需要timestamp
'2001-02-16 20:38:40'。
9、對於存儲大數據兩數據表，或業務中普遍應用的查詢條件，建立索引。
