[.NET] - Dataset oder SQLReader mit Liste - Performance bzw. sauberer Code

palaber

Captain
Registriert
Juni 2006
Beiträge
3.856
Hallo zusammen,

ich bin gerade am überlegen, was wohl besser / sauberer / schneller ist.
Ich möchte Zugriff auf eine DB-Tabelle haben. Aus dieser benötige ich ein paar Informationen.
Mit diesen werden dann bestimmte Operationen ausgeführt. Wenn diese abgeschlossen sind wird im entsprechenden Datensatz ein Wert zurück geschrieben.

Aktuell nutze ich ADO.NET und ein SQLClient Provider mit diesem fülle ich eine Liste von Objekten.
Das verwendete Objekt ist so aufgebaut, wie die benötigten Spalten eines Datensatzes.

Also: DB -> SQL Provider füllt Objektliste -> Liste wird durchlaufen und Operationen ausgeführt -> für jedes Element der der Liste werden Daten in DB zurück geschrieben.

Oder denkt ihr, es wäre besser ein DataSet zu erzeugen -> die Operartionen auszuführen -> das DataSet zu ändern und zurück zu schreiben?
 
Immer Dataset benutzen, wenn das möglich ist. Nur wichtig, daß du die Insert-,Update- und Deletecommands hinterlegst.

Edit: Solange du nur Daten liest, solltest du nur den Datareader benutzen, der ist die schnellste Option.
 
Mhh, für genauere Hilfen liste mal (gekürzt) die Abfragen auf, die durchgeführt werden. Wie lange dauert das Ausführen der Operationen?

Bist du auf ADO.NET festgelegt? Sonst würde ich dir empfehlen auf NHibernate mit Spring.Net Transaction/Session Management zurückzugreifen, dort könntest du auch so lange die Session aufhalten, bis der Wert zurückgeschrieben werden soll. Vielleicht geht das auch bei ADO.NET, kenn mich dort aber weniger aus. Ich find (Fluent)NHibernate aber wesentlich komfortabler.
 
Hallo,
warum verwendes du nicht das Entity Framework? Das nimmt dir jede Menge arbeit ab. Du musst dich nicht mehr mit DataSets & Co. rumschlagen und musst auch kein SQL mehr selbst schreiben, obwohl es natürlich die Möglichkeit noch gibt. Die Abfragen auf die Datenbank kannst einfach per LINQ machen. Einfacher geht es eigentlich nicht mehr ;-)

Greetz
hroessler
 
hroessler schrieb:
Hallo,
warum verwendes du nicht das Entity Framework? Das nimmt dir jede Menge arbeit ab. Du musst dich nicht mehr mit DataSets & Co. rumschlagen und musst auch kein SQL mehr selbst schreiben, obwohl es natürlich die Möglichkeit noch gibt. Die Abfragen auf die Datenbank kannst einfach per LINQ machen. Einfacher geht es eigentlich nicht mehr ;-)

Greetz
hroessler

Sehe ich genauso. Ein O/R-Mapper à la Entity Framework in Verbindung mit LINQ ist das Mittel der Wahl.

http://msdn.microsoft.com/de-de/library/vstudio/bb399182(v=vs.100).aspx
 
@ hroessler:
Soweit ich weiß wird LINQ ab .NET Framework Version 3.5 und höheren Versionen unterstützt. Die Anwendung muss aber noch unter .NET 2.0 laufen...

@ Thaxll'ssillyia:
Für jeden Datensatz dauern die Operationen etwa 1 Sekunde.
Es können zwischen 1 und ca. 500 Datensätze anfallen. Wobei wohl meistens etwa 10-50 Datensätze realistisch sind.

Und ja, bin auf ADO.NET festgelegt.

@ yummycandy:
So war auch mein Kenntnisstand: Das beim lesen der Datareader schneller ist.
Nur wenn ich jetzt ne List(of ...) anlege bin ich mir nicht mehr sicher, ob es so besser ist, wenn man über 50 Datensätze in Objekten abspeichert. Oder lieber einen Dataset nutzt.
 
Zuletzt bearbeitet:
palaber schrieb:
Soweit ich weiß wird LINQ ab .NET Framework Version 3.5 und höheren Versionen unterstützt. Die Anwendung muss aber noch unter .NET 2.0 laufen...
Mein Beileid. Ich verstehe nicht warum man sich heute noch .NET 2.0 beschränkt.
Aber das war vermutlich nicht deine Entscheidung, stimmts?

palaber schrieb:
Nur wenn ich jetzt ne List(of ...) anlege bin ich mir nicht mehr sicher, ob es so besser ist, wenn man über 50 Datensätze in Objekten abspeichert. Oder lieber einen Dataset nutzt.
Das DataSet ist jetzt nicht wirklich performant. Gerade bei 50 Objekten sollte die List<T> schneller sein. Hab's aber natürlich nicht nachgemessen.
 
Hatte damals nur mit SQLite herumexperimentiert und da war der direkte Zugriff (SQLiteCommand) in einigen Fällen deutlich schneller als der Datareader.... Will man jedoch sauberen Code ist man mit dem reader besser bedient.
 
can320 schrieb:
Hatte damals nur mit SQLite herumexperimentiert und da war der direkte Zugriff (SQLiteCommand) in einigen Fällen deutlich schneller als der Datareader....
Wie? Mit dem SqlCommand erzeugst du doch einen DataReader, oder wie kommst du sonst an die Daten?

Oder meinst du DataSet statt DataReader?
 
Warum noch .Net 2.0? Muss die Anwendung noch auf Windows 2000 laufen? Denn ab XP gibt es ja immerhin .Net 4.0 und da kannst du auch das EF6 (aber ohne Async) nutzen.
 
Hab das mal mit SQLite gemacht .. wie war das noch mit BEGIN und END?
20k Datensätze in < 10 Sekunden amigos (mit immerhin 5 columns :D)

mfg,
Max
 
Zurück
Oben