c# - Linq To SQL 删除+插入最佳实践

Question

如标题中所述，我需要执行删除 + 插入，我这样做:

 context.DeleteAllOnSubmit ( deleteQuery ) ;

 foreach ( var entry in entries ) 
      contex.InsertOnSubmit ( entry ) ;

 context.SubmitChanges();

正如在那篇文章中所写: Linq to SQL: execution order when calling SubmitChanges()

我读到删除操作是最后一个应用，但目前我看到我的逻辑工作(我确信删除+插入每天发生几十次)。我需要的是了解帖子是否错误或我的逻辑是否出于某种原因(将 linq 中的检查标志更新为 sql 数据模型？)只是幸运并避免了麻烦。

之后，我想知道当记录基数发生变化时进行“更新”的更好模式是什么。我的意思是在我的表中有一个主键来标识一个实体(一个实体有很多记录)和一个子键来标识同一实体(子实体)中的每条记录。我需要重新生成(因为可能会插入、编辑或删除某些子实体)所以我使用删除+插入(在我写入数据库的消息形式中只包含存在的实体和子实体，而不是已删除的)。

例如:

 ID     SubID    Data
 1      1_0      Father      
 2      2_0      Father
 2      2_1      Child 1
 3      3_0      Father
 3      3_1      Child 1
 3      3_2      Child 2

我既无法控制表格(以及其中的数据格式)，也无法控制消息(我用来写入或删除上面显示的表格)。

Answer 1

I read that the delete operation is the last one applied, but at the moment i see my logic work (i am sure that delete+insert happen dozen of times per day). What i need is understand if the post is wrong or my logic is and for some reason (update check flag in linq to sql datamodel?) only lucky and avoid the trouble.

帖子是对的，删了最后居然删了。

您的代码按设计运行，这并非偶然。

它实际上加载了所有要删除的记录，然后一一删除。这终于发生了。

这个不会失败也不会删错记录，但是有性能问题，可以引用很好msdn article对此

无论您对对象进行多少更改，都只会对内存中的副本进行更改。您没有对数据库中的实际数据进行任何更改。在您明确调用 DataContext 上的 SubmitChanges 之前，您的更改不会传输到服务器。

当您进行此调用时，DataContext 会尝试将您的更改转换为等效的 SQL 命令。您可以使用您自己的自定义逻辑来覆盖这些操作，但提交的顺序是由 DataContext 的一个服务编排的，称为更改处理器。

事件顺序如下:引用msdn

1. 当您调用 SubmitChanges 时，LINQ to SQL 检查已知对象集以确定是否已将新实例附加到它们。如果有，则将这些新实例添加到跟踪对象集中。 这就是我们一开始说插入的原因

2. 所有具有未决更改的对象都根据它们之间的依赖关系被排序到一个对象序列中。其更改依赖于其他对象的对象在它们的依赖性之后排序。 然后更新

更新删除完成后

在传输任何实际更改之前，LINQ to SQL 会立即启动一个事务来封装一系列单独的命令。

对对象的更改被一个一个地翻译成 SQL 命令并发送到服务器。

此时，数据库检测到的任何错误都会导致提交过程停止，并引发异常。

对数据库的所有更改都将回滚，就好像从未发生过提交一样。 DataContext 仍然有所有更改的完整记录