LINQ-to-SQL und Massenänderungen werden sehr langsam übermittelt.

Question

Ich iteriere über eine Gruppe von Instanzen einer LINQ-to-SQL-Klasse.

Während dieser Iteration mache ich Änderungen, markiere einige zum Löschen und füge sogar neue in den Datenkontext ein. Wenn ich mit der Iteration fertig bin, führe ich context.SubmitChanges() aus - es funktioniert, aber es ist erstaunlich langsam. Ich verwende lokal eine Express-Version von MSSQL 2008.

Außerdem habe ich festgestellt, dass der UPDATE-Befehl, den es generiert, für die Zeilen, die aktualisiert werden müssen, lautet UPDATE SET ..... WHERE @p1 = ... UND @p2 = ..., also auf allen Feldern/Spalten. Ich habe den Primärschlüssel in der Tabelle und auch im DBML-Schema definiert, aber anscheinend vergleicht es trotzdem alle Spalten für den UPDATE-Befehl anstatt nur den Primärschlüssel.

Irgendwelche Ideen?

---

Update:

Wie ich befürchtet habe, lag es daran, dass ich vergessen hatte, das LINQ-to-SQL-Schema nach der Definition des Primärschlüssels und der erforderlichen Indizes in der Tabelle zu aktualisieren.

Die betroffene Menge beträgt etwa 40k Zeilen, und ich bin zufrieden mit der Leistung meiner Lösung.

Wenn die Menge steigen sollte, werde ich mir die von Marc erwähnten Konfliktüberprüfungseigenschaften ansehen.

Answer 1

Das WHERE @p1 = ... UND @p2 = ist mit der Parallelitätsprüfung verknüpft. Sie können dies pro Spalte deaktivieren oder (besser) stattdessen einen Zeitstempel/Rowversion verwenden (Hurra!). Schauen Sie sich die Eigenschaften "Update Check" und "Zeitstempel" im dbml-Designer an. Das Hinzufügen einer rowversion zur Tabelle und das erneute Importieren der Tabellen in das dbml wären meine bevorzugte Option.

Von welcher Größenordnung sprechen wir hier? Hunderte? Tausende? Mehr?

LINQ-to-SQL (und EF) führen Änderungen auf objektorientierter Basis durch, daher zeilenweise. Es gibt eine Grenze, bei der die setbasierten Updates der richtige Weg sind und Sie eine gespeicherte Prozedur schreiben müssen, die die gesamte Arbeit auf einmal erledigt.

Wenn Sie keine massiven Änderungen vornehmen, es aber dennoch lange dauert, würde ich erwarten, dass das Problem an fehlenden angemessenen Indizes auf den Primärschlüsseln liegt.