資料庫設計與效能 (SQL Server Compact)
藉由正確設計 SQL Server 資料庫與發行集，您可以大幅改善 SQL Server Compact 3.5 (SQL Server Compact 3.5) 應用程式效能。下列各節將說明可以用來增強效能的方法。
使用資料庫非正規化
正規化資料庫可避免資料的功能相依性，因此，更新資料庫既簡單又有效率。不過，查詢此資料庫時，可能會需要使用許多資料表聯結來結合資訊。隨著聯結資料表的數目增加，查詢執行時間也會大幅增加。因此，正規化資料庫可能未必是最佳選擇。含有適當非正規化資料量的資料庫可減少必須聯結在一起的資料表數目，不會造成更新程序過於複雜。所以，這通常是一項良好的折衷方案。
注意
一般來說，如果您的查詢多數需要聯結五或六個以上的資料表，您就應該考慮使用非正規化。
此外，資料庫非正規化有許多類型。例如，假設您的資料庫有兩個資料表：Orders 和 Order Details。Orders 資料表含有客戶訂單的相關資訊。而每份訂單的個別產品則是包含在 Order Details 資料表中。假設您想要查詢每份訂單的總金額。首先，您必須先判斷各項產品的金額 (單位 * 單價 – 適用折扣)。然後，您必須按訂單將金額分組。這項查詢看起來應該像這樣：
SELECT "Order ID", SUM("Unit Price" * Quantity * (1.0 - Discount))
AS Total FROM "Order Details"
GROUP BY "Order ID"
Order ID Total
----------------------------------------
10000 108
10001 1363.15000915527
10002 731.800003051758
10003 498.180023193359
10004 3194.19999694824
10005 173.400009155273
10006 87.2000007629395
10007 1405
10008 1171
10009 1530
10010 470
... ...
(1078 rows affected)
這項查詢的計算方式並非一般作業。如果訂單數量龐大，查詢可能需要花一段長時間才能執行完成。因此，替代方案是在下訂單時先計算訂單的金額，然後將金額儲存在 Orders 資料表的其中一個資料行。透過這種方式，您只要查詢預先計算的資料行，即可傳回所需的資訊：
SELECT "Order ID", "Order Total" AS Total FROM Orders
藉由建立預先計算的資料行，您便可節省大量查詢時間，不過這項方式會要求您在資料表中維護額外的資料行。
在可變長度資料行與固定長度資料行之間選擇
瞭解使用可變長度資料行與固定長度資料行的優缺點，在您設計資料表時會很有幫助。可變長度資料行可減少資料庫大小，因為它們只需要使用儲存實際值的空間即可。固定長度資料行則永遠要使用結構描述所定義的最大空間，即使實際值是空的也一樣。但是可變長度資料行的缺點在於，某些作業效率不如固定長度資料行的作業效率。例如，如果可變長度資料行一開始很小但 UPDATE 導致其體積大幅增長時，其記錄可能就必須重新放置。此外，經常更新會導致資料頁面隨著時間過去而形成許多小片段。因此，如果資料長度不會大幅變動但會經常執行更新，我們建議您使用固定長度資料行。
建立較小資料列長度
一個頁面可容納的資料列數目是取決於每個資料列的壓縮程度。如果資料列越小，頁面就可容納越多資料列。因此，在含有壓縮資料列的資料表上進行單一磁碟作業時，可擷取更多資料列，讓作業更有效率。此外，在儲存引擎快取記憶體中納入越多資料列，可能會改善叫用比率。而且壓縮資料列還可避免浪費資料頁面上的空間，較大的資料列通常會造成浪費。
請考慮以下這項極端的範例：如果記錄大小大於資料頁面的一半，那麼幾乎每個資料頁面上一半的空間都被浪費。此時某些資料庫設計工具會選擇採用寬資料表設計，並且將主機資料庫結構描述向下傳送至裝置。但這可能不是一項具有效率的設計。其中一項可能的方式為分割最關鍵的資料表。假設您有一個資料表，其中某些資料行具有非常穩定的值，而其他資料行的值則會經常變更。此時，將資料表分割為二會很有幫助：一個含有經常參考的資料行，而另一個則含有穩定的資料行。當您建立這兩個資料表之後，您就會擁有較小資料行長度的所有優點。唯一的缺點就是，需要使用聯結才能結合資訊。
使用較小索引鍵長度
索引是指建立資料表的排序子集。它可讓您進行快速範圍查詢以及排序順序。較小的索引鍵比較大的索引鍵需要更少的空間，並且更有效率。此外，壓縮主索引鍵尤其是一項好方法，因為其他資料表經常會將主索引鍵視為外部索引鍵來參考。如果沒有自然壓縮的主索引鍵，您可以改用實作的識別欄位做為整數。
含有一個或少數索引鍵資料行的索引稱為窄索引。含有許多索引鍵資料行的索引稱為寬索引。寬索引通常會與大型索引鍵長度相關。極端的範例為將每個資料行納入資料表的索引。建立此一索引後，您可有效複製原始資料表。不過，就資料庫大小與查詢效能而言，這種索引並沒有效率。
發行集發行項的類型與選項
當您在 SQL Server 2008 中建立發行集時，您可以在發行集中選擇兩個發行項選項。這些選項可控制篩選以及發行者與訂閱者類之間的資料流程，分別是：
- 僅供下載 (唯讀)
有時候，您想要在智慧型裝置上查詢的資料只儲存在查詢資料表中。例如，您的使用者可能必須在他們的智慧型裝置上瀏覽公司目錄，不過無法編輯與變更這項資訊。僅供下載的發行項類型便適用於此用途。這種發行項的體積較小，因為裝置上未儲存任何中繼資料，而且在同步處理過程中可減少網路流量。 - 完整分割
透過 SQL Server 2008 中的完整分割發行項，所上載的變更都只會對應至單一分割識別碼。雖然這較為快速，不過有幾項限制：- 發行項中的每個資料列必須屬於單一分割識別碼。
- 每個發行項只能發行給單一發行集。
- 訂閱者不能插入不屬於其分割識別碼的資料列。
- 此外，使用完整分割發行項時，也會影響篩選。下列限制適用於篩選：
- 訂閱者無法更新篩選所涉及的資料行。
- 在聯結篩選階層中，一般發行項不可以是完整分割發行項的父系。
- 完整分割發行項為子系的聯結篩選必須將 join_unique_key 的值設為 1。
- 每個發行項只能有單一子集或聯結篩選。發行項可以含有子集篩選而且是聯結篩選的父系，但不可以含有子集篩選而且是聯結篩選的子系。