Ich mag ORM-Tools, aber ich habe oft gedacht, dass es für große Updates (Tausende von Zeilen) ineffizient zu laden, zu aktualisieren und zu speichern ist, wenn etwas wie
%Vor%würde viel bessere Leistung bringen.
Wenn Sie jedoch aus Performance-Gründen diese Route herunterfahren möchten, wie würden Sie dann sicherstellen, dass alle im Speicher zwischengespeicherten Objekte korrekt aktualisiert wurden.
Nehmen wir an, Sie verwenden LINQ to SQL, und Sie haben an einem DataContext gearbeitet. Wie stellen Sie sicher, dass sich Ihr hochperformantes UPDATE im Objektdiagramm des DataContext widerspiegelt?
Dies könnte ein "Sie nicht" oder "Trigger auf der DB verwenden, um .NET-Code aufzurufen, der den Cache löscht" usw., aber ich bin daran interessiert, allgemeine Lösungen für diese Art von Problem zu hören.
Sie haben recht, in diesem Fall ist es nicht effizient, ein ORM zu verwenden, um Datensätze zu laden, zu ändern und dann zu persistieren. Mein Prozess läuft ungefähr so ab.
1) Frühe Implementierung verwenden ORM, in meinem Fall NHibernate, ausschließlich
2) Wenn die Entwicklung reifer wird, identifizieren Sie Performance-Probleme, die große Updates beinhalten.
3) Refactor diese auf SQL oder SP-Ansatz
4) Verwenden Sie den Befehl Aktualisieren (Objekt), um zwischengespeicherte Objekte zu aktualisieren,
Mein großes Problem war, andere Kunden darüber zu informieren, dass das Update stattgefunden hat. In den meisten Fällen haben wir akzeptiert, dass einige Clients veraltet sein werden, was bei der normalen ORM-Verwendung sowieso der Fall ist, und überprüfen Sie dann einen Zeitstempel auf update / insert.
Die meisten ORMs verfügen auch über Einrichtungen, um große oder "Bulk" -Updates effizient durchzuführen. Die Stateless Session ist ein solcher Mechanismus, der in Hibernate for Java verfügbar ist und offenbar in NHibernate 2.x verfügbar sein wird:
ORMs sind großartig für eine schnelle Entwicklung, aber Sie haben Recht - sie sind nicht effizient. Sie sind großartig darin, dass Sie nicht über die zugrunde liegenden Mechanismen nachdenken müssen, die Ihre Objekte im Speicher in Zeilen in Tabellen und wieder zurück konvertieren. Oft wählt das ORM jedoch nicht den effizientesten Prozess dafür aus. Wenn Sie wirklich Wert auf die Leistung Ihrer App legen, empfiehlt es sich, mit einem Datenbankadministrator zusammenzuarbeiten, um die Datenbank zu optimieren und die Abfragen entsprechend anzupassen. (oder zumindest die grundlegenden Konzepte von SQL selbst verstehen)
Bulk-Updates sind ein fragwürdiges Design. Manchmal scheinen sie notwendig zu sein; In vielen Fällen kann jedoch ein besseres Anwendungsdesign die Notwendigkeit von Massenupdates beseitigen.
Oft hat ein anderer Teil der Anwendung bereits jedes Objekt einzeln berührt; das "Bulk" -Update sollte in dem anderen Teil der Anwendung durchgeführt worden sein.
In anderen Fällen ist das Update ein Vorspiel für die Verarbeitung an anderer Stelle. In diesem Fall sollte das Update Teil der späteren Verarbeitung sein.
Meine allgemeine Designstrategie besteht darin, Anwendungen zu refaktorieren, um Massenupdates zu vermeiden.
ORMs werden nicht so effizient sein wie handgefertigtes SQL. Zeitraum. Genau wie handgefertigte Assembler werden schneller als C #. Ob dieser Leistungsunterschied zählt, hängt von vielen Dingen ab. In einigen Fällen kann die höhere Ebene der Abstraktions-ORMs Ihnen mehr wert sein als eine höhere Leistung, in anderen Fällen nicht.
Das Verschieben von Beziehungen mit Objektcode kann ziemlich nett sein, aber wie Sie zu Recht darauf hinweisen, gibt es potentielle Probleme.
Ich werde mich hier nicht wiederholen, sondern nur auf mit einem ORM oder plain zeigen SQL?
Tags und Links sql database performance caching orm