现在，为什么你不选择这么做呢?这有一些原因：

此时你需要有事务日志备份。如果你想从备份中恢复一个文件或者文件组，你同时也需要恢复与它们一起创建的事务记录备份，从而使整个数据库能够处于一个一致的状态。在SQL Server 2000 和 2005中，你需要使用Full Recovery或者Bulk-Logged Recovery模式来使它成为可能。应该指出SQL Server的实现者们并没有尽他们的努力来完成判断从上一次备份一个文件或者文件组是否已经被修改了的功能。如果没有被改变，那么事务记录是没有什么必要的。总的来说，还是需要事务记录备份的，如果你现在还没有一个备份事务记录的恢复或者备份计划，那么现在就创建一个吧。

在要恢复的文件或者文件组中的表格与数据库中其他的表格之间的数据不一致性成为需要考虑的一个问题。如果你有相互之间依赖的表格，并且这些表格没有被存储在相同的物理文件或者文件组中(这有时是不可避免的)，仅仅恢复一个文件或者文件组可能会导致它与数据库其他部分不同步。

当你在数据库中只有一个文件组。如果你的所有的数据仅仅存储在一个文件或者文件组中，并且它又不是一个特别大的数据库时，会发生什么事情呢?那时恢复一个文件或者文件组的努力就变的没有什么意义了。

选择性的恢复文件或者文件组的主要原因是当恢复数据库很大，以至于恢复整个数据库的代价很大的时候，使得对数据库的局部损坏的恢复成为可能。在一个非常小的轻量级的数据库里，和nonproduction系统中，或者数据库中只有一个文件组的时候，实现选择性的恢复功能就显的没有太大的意义，因为这时恢复整个数据库和恢复单个的文件或者文件组没有什么太大的区别。

大多数时候当人们想使用文件或者文件组恢复时，他们实际上是想把一个特定的表格恢复到先前的一个点的时刻的状态。这在SQL Server中不是一个显式支特的特性，但是存在这么做的方法，倘若你不介意由于采用这种方法而需要手工的来管理可能产生的不一致。如果你手边就有一个数据库备份的话，你可以简单的恢复那个备份，仅仅把它看作是相同数据库的不同名字的实例。接着，通过事务记录把数据库向前滚动到指定的点(如果需要这样做的话)，然后手工的把当前的数据库拷贝到目标数据库中。