Laden...

DataSet vs. DataReader

Erstellt von inTrance vor 18 Jahren Letzter Beitrag vor 18 Jahren 3.931 Views
inTrance Themenstarter:in
170 Beiträge seit 2005
vor 18 Jahren
DataSet vs. DataReader

Hallo!

Ich schreibe an einem DB-Frontend, dass die Daten u. A. in einem Grid anzeigen
soll - ganz wie von unzähligen Tools gewohnt. Mit Hilfe des Grids sollen auch
Datensätze bearbeitet / gelöscht / hinzugefügt werden können.

Meine Frage ist: Soll ich für die Anbindung an die DB lieber das DataSet ver-
wenden oder lieber den DataReader und alles nötige selbst implementieren?

Was wird in Punkto Performance und Flexibilität besser geeignet sein? Ich möchte
auch so Dinge realisieren, wie das Editieren von Daten ohne Primary, wozu das
DataSet-Binding ja nicht ohne weiteres in der Lage ist.

Ich weiß dieses Thema wurde teilweise schon behandelt, aber ich bin mir halt
nich so sicher, ob das hier vielfach empfohlene DataSet wirklich auch noch hin-
haut, wenn es um die Detaillösungen geht, die MS einfach nicht vorhergesehen
und implementiert hat.

Ach ja: Gibt es eigentlich auch eine Möglichkeit an die "Raw"-Daten einer DB zu
kommen. Also vollkommen unformatiert und beeinflusst, sondern genau das, was
in der Datenbank steht?

Bin für Tipps dankbar 🙂

inTrance

D
155 Beiträge seit 2005
vor 18 Jahren

Also ich nehme an du darfst keinen Key verwenden (denn sonst würdest du dir echt Berge in den Weg legen).

Also noch erstmal der Vorteil des DataReaders:
Schnell
Daten werden syncron ausgelesen, heißt du kannst nach z.B. 1000 Datensätzen das auslesen stoppen.

Nachteile:
Connection muss von Hand geöffnet werden
Nur Forward Reading, man kann nicht mehr einen bereits ausgelesenen Datensatz einsehen.
Der DataReader muss wieder geschlossen werden
Es kann immer nur ein DataReader eine Verbindung nutzen (auf jeden Fall in 1.1)

Zu den DataTables bzw. dem DataSet
Vorteile:
Die Verbindung muss nicht geöffnet werden
DataAdapter übernehmen die komplette Verbindung zur Datenbank
Schemen werden direkt in das DataSet geladen.
Nachteile:
Langsamer als der DataAdapter
Daten werden komplett ausgelesen

Also ich tendiere eher zum DataAdapter in den meißten Situationen ist wie gesagt Problemabhängig.

W
799 Beiträge seit 2004
vor 18 Jahren

Sobald es um sehr große Datenmengen geht, verbietet sich das DataSet von alleine, weil es halt schweinelangsam wird.

inTrance Themenstarter:in
170 Beiträge seit 2005
vor 18 Jahren

Aropos auslesen: Aber der DataReader lädt die Daten doch auch nur einmalig
beim Execute, oder nicht?

Hat jemand vielleicht einen Hinweis, wie das mit dem Auslesen der Raw-Daten
aussieht?

Danke schon mal soweit für die Tipps - über noch mehr Erfahrungen bin ich
natürlich immer happy 🙂

F
529 Beiträge seit 2003
vor 18 Jahren

Ich würde uneingeschränkt zum DataReader raten, weil man die Verbindung selbst im Griff hat. So bekommt man u.U. keine Probleme mit sich als störend erweisenden Eingenschaften des DataSet. Leider kann immer nur ein Datareader pro Verbindung gleichzeitig auf Daten zugreifen. Aber das ist kein allzugroßes Problem.

Besuchen sie das VisualC++ - Forum

inTrance Themenstarter:in
170 Beiträge seit 2005
vor 18 Jahren

Ich seh gerade: An die Roh-Daten zu kommen, ist sowohl bei MSSQL als auch
bei MySQL kein großes Problem. Die Reader implementieren entsprechende
Methoden.

Für das Nur-Ein-Reader-Pro-Con-Problem lassen sich ja leicht entsprechend viele
Connections öffnen. Die großen DBMS sind ja eh drauf ausgelegt.

Die Features des Grids lassen sich doch trotz DataReader voll nutzen (wenn halt
auch manuell), wie z. B. diese Fehler-Icons in der Zelle usw.? Oder würdet ihr
vom DataGridView dann ganz abraten bei Verwendung des Readers?

// Edit: Ach ja: Wenn ich den Reader verwende, sollte ich das Grid dann über
dieses Event-Systems des virtuellen DataGridViews füllen, oder sollte ich alles
manuell setzen? Ein Caching-System würde ich natürlich sowieso implementieren.

D
155 Beiträge seit 2005
vor 18 Jahren

Also dass ist jetzt echt nicht leicht.

Wenn es sich um eine Client Application handelt (davon gehe ich aus) würde ich folgendes sagen:

Ich würde erstmal mit dem DataAdapter so arbeiten wie er ist. Dazu würde ich generell das Laden der Daten in eine Klasse auslagern. Wenn noch Zeit übrig bleibt kann man noch den Reader schnell implementieren und es sollte so auch funktionieren.

Toll wäre auch ein Mix: Die Schemas werden per DataAdapter geladen und die Daten an sich per DataReader. Dann kannst du Grids verwenden (denn du hast ja das Schema) und die Geschwindigkeit des DataReaders.

inTrance Themenstarter:in
170 Beiträge seit 2005
vor 18 Jahren

Toll wäre auch ein Mix: Die Schemas werden per DataAdapter geladen und die Daten an sich per DataReader. Dann kannst du Grids verwenden (denn du hast ja das Schema) und die Geschwindigkeit des DataReaders.

Wofür brauche ich denn das Schema? Setzt das die Column-Properties des Grids?
Also welches Format welche Spalte hat? In der Hinsicht muss ich sowieso nach-
arbeiten, wie ich bei ersten Tests mit dem Grid gesehen hab.

D
155 Beiträge seit 2005
vor 18 Jahren

Original von inTrance
Die Features des Grids lassen sich doch trotz DataReader voll nutzen (wenn halt
auch manuell), wie z. B. diese Fehler-Icons in der Zelle usw.? Oder würdet ihr
vom DataGridView dann ganz abraten bei Verwendung des Readers?

Dazu brauchst du die Schema Infos. Ich kann mir nicht vorstellen ganz ohne Metadaten zu arbeiten...

S
1.047 Beiträge seit 2005
vor 18 Jahren

was verstehst du denn unter raw-daten?

wenn du den datareader hast, gibts methoden die dir einen string, ein int usw. zurück geben... mehr raw geht doch garnicht mehr...

F
529 Beiträge seit 2003
vor 18 Jahren

Der DataReader kann einem doch auch gut die Schemadaten zurückgeben. Der Datareader hat eine Funktion GetSchemaTable(). Damit bekommt man das Schema in einem DataSet zurück.

Besuchen sie das VisualC++ - Forum