SQLCE使用本地数据库优化

一、数据绑定

1、使用数据虚拟化和SKIP/TAKE

使用 Skip 和 Take 方法可确保直到需要在 ListBox 控件中显示数据时才将数据库中的数据加载到内存中。

例如，以下代码显示了如何从数据库中检索第 501 到 550 条记录。

return

(from f in App.FeedsDB.Feeds

select f).Skip(500).Take(50);

由于在用户滚动列表时执行此加载操作会产生开销，因此该技术应该仅限于数据集较庞大（大于 150 项）的情况。

对于较小的数据集，将整个集合加载并绑定到内存中可能会提高性能。

2、双向绑定数据

LINQ to SQL 数据上下文中的实体可以和任何其他“简单传统 CLR 对象”(POCO) 一样，

以双向数据绑定的方式绑定到 UI 控件。

在对实体进行数据绑定时，请考虑以下几点：

a.若要维护与本地数据库之间的关系，应用程序必须绑定到完整实体，而不是部分投影。

b.若要保存对数据上下文中实体所做的更改，请使用 SubmitChanges 方法。

二、插入、更新和删除

1、大批量编辑

在极少情况下，应用程序可能需要更新本地数据库中的多条或全部记录。

例如，在一个包含 10,000 个客户的表中，有一个名为 CustomerType 的属性。

CustomerType 属性可以指派为以下值：Standard、Premiere 或 Exclusive。

假设有 5,000 个客户的 CustomerType 被指派为Exclusive，并且需要将此类别重命名为 Platinum。

不建议使用的一种方法是选择所有 Exclusive 客户，然后遍历要将其类型更新为 Platinum 的每个客户。

对数据上下文完成所有更改之后，调用 SubmitChanges 方法。

在此方案中，所有 5,000 个对象都会加载到内存中，这可能会使设备出现问题。

因此，我们建议使用对设备内存产生较少开销的方法：使用单独的数据上下文批量执行更新。

对于此方法，使用一个查询：对列表进行排序，并通过 Skip和 Take 方法确保对数据进行适当分页。

完成批处理之后，对 DataContext 对象调用 Dispose 以确保垃圾回收器清理上下文和相关联的缓存对象。

或者，可以将 DataContext 对象封装在 using 语句中，以便它自动释放。

2、通过版本列实现快速更新

优化表上更新操作性能的最简便方法之一是添加版本列。

这种优化方法特定于 Windows Phone 的 LINQ to SQL。

例如，在实体中添加以下代码：

 [Column(IsVersion=true)]  private Binary _version;

实现这种优化可极大地提高大量更新的性能。

3、将更改提交到数据库中

在将更改提交到数据库时，最佳批次大小和提交频率的确定在很大程度上依赖于应用程序方案。

请考虑以下事项：

在更改实际保存到文件系统之后 SubmitChanges 方法才会返回。

此过程会花费一段时间，不应随意使用。

例如，如果每次用户选择或取消选择 CheckBox 控件时，应用程序都提交更改，则会产生极大的开销。

但是，提交事务所需的时间会随着更改数量的增多而增加。

如果尝试在应用程序正在退出时提交过大的批处理，则在应用程序进程关闭之前，提交操作极有可能无法完成。

通常，提交用户操作直接产生的更改是一种非常冒险的方式，因为如果数据丢失，就无法再恢复。

对于可恢复的更改（例如，云服务中的缓存数据），可以构建较大的更改集。

这是因为如果退出时数据没有成功提交，您始终可以还原这些数据。

三、使用BLOB数据

如果应用程序需要存储和检索大量的二进制大型对象 (BLOB) 数据，可以将该数据直接存储在本地数据库或独立存储中。

可以使用 binary(n)、varbinary(n) 或 image 数据类型将 BLOB 数据直接存储在本地数据库中。

使用这种方法时，建议使用不同的最大缓冲区大小值来测试 BLOB 查询性能。

提高连接字符串中的 max buffer size 参数有助于提高 BLOB 的检索性能，但同时会增加应用程序对内存的消耗。

四、极大限度的减少内存使用量

1、INotifyPropertyChanging

LINQ to SQL 更改跟踪是通过维护每个对象的两个副本进行工作的。

对象的一个副本仍然保持为最初从数据库中具体化的原样。另一个副本由应用程序进行更改。

然后，当提交更改时，LINQ to SQL 可以确定哪些属性已进行更新，并且只将这些更改提交到数据库事务中。

默认情况下，LINQ to SQL 会在对象具体化时创建两个对象副本。

但是，特定的事务中通常仅修改具体化集合中的少量对象。在这种情况下，就没有理由保留对象的第二个副本。

INotifyPropertyChanging 接口允许应用程序在修改属性时通知 DataContext，该属性最终将作为更新提交到数据库。

DataContext 可以将该通知用作创建副本的触发器。这样，就只需要复制实际进行更改过的项。

实现 INotifyPropertyChanging 接口的方法如下：

将以下代码添加到您的实体中，然后在每个实体属性的 setter 中调用NotifyPropertyChanging 方法，最后再更改值。

    public event PropertyChangingEventHandler PropertyChanging;
        // Used to notify that a property is about to change     private void NotifyPropertyChanging(string propertyName)     {       if (PropertyChanging != null)        {           PropertyChanging(this, new PropertyChangingEventArgs(propertyName));        }     }

2、ObjectTrackingEnabled

移动应用程序通常具备只读的查询方案，在这些方案中，只需要显示数据，用户是无法对数据做出更改的。

在这种情况下，可以完全关闭更改跟踪基础结构以节省内存。

可通过将 DataContext 上的 ObjectTrackingEnabled 属性设置为 false 来完成此操作。

五、执行模型注意事项

1、快速应用程序切换

当用户从应用程序向前导航时，如果操作系统将该应用程序置于休眠状态，则其所有线程都会停止，并且不再进行任何进一步的处理。

但是，操作系统会代表应用程序执行某些操作，包括某些无法完全停止的数据库操作。

特别是，非常复杂的查询（例如具有重要的分组和排序功能的查询）可能需要一段时间才能完成，

并且其运行时间可能会超过允许应用程序暂停的时间，在这种情况下，应用程序会被操作系统完全逻辑删除。

为了确保您的应用程序可以充分利用快速应用程序切换功能，请避免在取消激活期间执行可能会产生较大开销的查询。

2、逻辑删除

当应用程序被逻辑删除时，基础数据库连接会关闭。

若要在逻辑删除之后返回到以前的状态，应用程序需要恢复它在被逻辑删除之前执行的所有查询。

六、查询性能

1、建立索引

系统会自动为指定为主键的数据库列创建索引。此后在表中创建的任何其他索引都称为次要索引。

次要索引应该用于实体中任何常用的查询属性，包括用于确定结果排序顺序的属性。

对于通常要进行排序的属性，应该使用适当的排序顺序（升序或降序）。默认情况下，索引按升序排序。

若要在索引属性中明确指定排序顺序，请在列名称后面加上 ASC 或 DESC 来分别指定按升序和降序排序。

例如，以下实体属性指定了在 OrderID 列中按升序排序，在 Quantity 列中按降序排序的索引。

[Index(Column=”OrderID ASC, Quantity DESC”)]

2、编译查询

默认情况下，每次在运行时执行查询时，LINQ to SQL 都会将 LINQ 表达式目录树转换为对应的 Transact-SQL 语句。

对于执行频率很高的查询（例如，查找包含此 ID 的记录），每次生成对应 Transact-SQL 所产生的开销都非常浪费。

为了避免发生这种效率低下的情况，可以使用编译查询。

编译查询会提前生成参数化的 Transact-SQL 语句，然后可以通过不同的值重复使用这些语句。