在一個數據庫應用程序中，程序是從一個健全的數據庫模型開始的。明白了這一點後，我們來看幾種可以優化數據庫模型的方法，通過這些方法可以提高查詢效率。
(1) 少許的逆規范化(denormalization)大有幫助。盡量避免這樣的數據庫模型：它有一個名為Gender的表，表中有3個值。如果你有一個1:1關系的表，而且它經常被它的父表訪問，那麼你可以考慮合並這兩張表。
(2) 讓應用程序多承擔一些責任。如果可以通過應用程序更容易地析取數據，為什麼還要生成視圖來強制數據以某種確定方式出現呢？
(3) 對數據進行水平分割。如果你有一個表示Web站點點擊率的表，則可考慮把它按月份劃分為12個表。如果數據是分布式的，那麼你的負荷就變成了原有的1/12。這也可以讓你把一些數據放在各個獨立的服務器上，然後使用分布的劃分視圖來更新和查看數據。這樣做使你可以對當前月份使用更加積極的索引策略，並且對已經過去的月份使用更高的填充度。
(4) 在行中保持盡可能少的內容。換句話說，不要使用一個char(255)類型來存儲一個用戶名的值，這只會造成空間的浪費。
(5) 為了不破壞引用的完整性，要避免使用觸發器。使用外鍵約束要快得多，並且這種約束更適合處理大多數的操作。
(6) 避免使用text類型的字段。嘗試找出對字段的確切要求是什麼。如果你准備最多插入2000個字符，那麼使用varchar(2000)會更加有效。
(7) 除非你要使用多種語言，否則不要使用像nvarchar和ntext這樣的Unicode數據類型。然而要牢記，當你使用DTS從另一個數據源(如Access)轉換數據的時候，DTS經常在服務器上創建Unicode的列。如果你的公司打算使用多語言，那麼你就會需要這些數據類型。
(8) 避免在標識列上創建聚集索引。聚集索引對於范圍查詢執行起來更好，如一個日期。如果在標識列上存在聚集索引，你的數據就有收到“熱點”的風險。注：“熱點”是由於很多人更新同一數據頁所引起的。
(9) 可能的話，就不允許列為NULLS。如果你知道你總是會得到地址信息的話，那麼你就不需要為空的列。處理NULLS會增加額外的開銷。
(10) 在某些情況下，如果表中存在惟一的數據列，那麼要避免使用標識列。例如，如果用戶名的值是惟一的，就不要另外創建沒有必要的鍵。這樣可以防止從子表中創建不必要的連接來確定用戶名。這可能會占用一些存儲空間，但可以給你節省大量的查詢時間。要靈活處理這種實際情況，但如果行中已經存在惟一的值，那麼為什麼還要人工去給它分配一個呢？
