我可以想象，如果您可以设置数据库，以便它根据需要自动收缩和修复，这是相当彻底的。这就是为什么缺乏关于最佳实践的文献；有一种普遍的假设认为它“只是起作用”。所以你在这个领域得到的任何指导都是模糊的。

以下是http://www.microsoft.com/web/library/Details.aspx?id=sql-server-2008-compact-express-depoly-manage网播的(部分)引文

维护Server版本的

非常类似于管理任何其他多用户数据库，这意味着我们可以选择进入并处理文件组，我们可以处理备份选项和恢复模型等等。但是，当我们处理紧凑版本或Service时，我们没有那么多的选项。实际上，我们唯一的选择就是如何处理收缩和修复问题。

这是另一个来自http://msdn.microsoft.com/en-us/library/ms838028.aspx#youcantakeitwithyou_sqlserverce_topic4的MSDN

请注意，它们给出了数据库体系结构的详细信息，但仍然没有给出维护计划。他们的建议是:当数据库开始变慢时去做。还请注意，这一建议大约在2005年左右，此后情况有所改善；即维护程序现已自动化。

将您的房子(或数据库)按顺序排列

SQLServerCE2.0中大型数据库性能的另一个重要因素是数据库结构本身的组织。当应用程序修改数据库的内容时，记录在数据库文件结构中变得更加随机分布。在大量插入和删除之后，这一因素尤其正确。为了确保对数据库的最佳访问，在对内容进行任何实质性更改后，对数据库进行压缩。

除了恢复未使用的空间外，在数据库上执行契约还会对性能产生两个显著影响:第一，它按主键按顺序存储所有表记录；第二，更新查询处理器使用的统计信息。

按主键对记录进行排序可以显著改善主密钥访问。这是由于Server (和大多数其他数据库)面向页面的特性所致。Server没有将单个记录从数据库加载到内存中，而是加载称为页的记录块。当数据库记录按主键顺序分组时，加载包含一条记录的页面将自动加载具有类似主键值的记录。对于大多数应用程序来说，这会导致所谓的良好“命中率”，这意味着当应用程序访问连续的数据库记录时，包含这些记录的页面很可能已经在内存中并可以直接访问。当记录更随机地分布时，通常是在大量插入和删除之后发生的，因此命中率很低，需要SQL Server CE从数据库文件中检索更多的页面来访问相同数量的记录。

查询处理器统计数据影响查询处理器如何确定查找记录的最佳方法。诸如是使用键还是进行顺序扫描来定位特定记录之类的决策都受到查询处理器统计信息的影响。随着统计数据变得陈旧，查询处理器可能做出的决策可能会少于最优。执行契约会刷新这些统计数据。

我同情你在Access数据库方面的经验。但是，我认为您会发现您在Server方面的经验几乎没有什么相似之处。