Zitat von
Christof:
Zitat von
Robert_G:
Zitat von
Christof:
Ado.net nicht so gern, da Probleme mit großen Datenmengen.
Wie geht das mit dem Firbird .net unter delphi bzw. c#.
Den kapiere ich jetzt nicht.
Solange du Collections/Listen statt einem DataSet benutzt, sollte es sehr flott sein.
Was heißt sehr flott! Ich habe eine Datenbank mit einer Million Datensätze ! Ist dann immer noch schnell mit Collections/Listen?
Ich dnke mal, du wirst keine Million DS in eine Collection laden wollen, oder?
Wenn doch sollte man den Begriff "flink" relativieren.
Das System.Data.DataSet ist deshalb so lahm, weil es eine Art Offline-Datenbank ist. Du kannst schließlich Foreign-Keys, prim. Keys & Co definieren. Das bedeutet immer eine Menge Overhead (auch wenn du nix davon in deinem DS verwendest.)
Außerdem boxt eine DataRow ständig die einzelnen Werte in ein Object und wieder zurück. -> Das ist in .Net ziemlich lahm. (für Wertetypen á la structs, int, enums, ...)
Bei einer Collection kannst du eine Klasse als Element definieren, die deinem Datensatz bzw. der Logik dahinter entspricht. -> weniger oder kein Boxing.
Außerdem kann man so hübsch type-safe arbeiten ohne sich ständig einen Wolf zu casten.
Zitat von
Christof:
Aber eine Kurzanleitung als Tutorial für Firebird wäre nicht schlecht. Ich denke das auch andere ähnliche Probleme haben werden.
Vielleicht etwas für die Tutorial-Ecke ?
Wohl nicht für
FB speziell, aber ein kleines Round Up über die Verwendung von
ADO.Net Providern, DataBinding, IList & ICollection wäre sicher vorteilhaft.
Vielleicht finde ich dafür nach meinem Urlaub Zeit und Lust.
(Wäre dann aber in c# nicht in Delphi.Net)
p.s.:
ADO.Net ist ein nettes Wort, bedeutet aber nix weiter als eine Sammplung von Komponenten, die IDbConnection, IDbCommand & Co implementieren. Da sie nicht direkt ableiten müssen gibt es auch keine generelle Performancebremse (außer der Provider wurde etwas verlangsamt: siehe MS Oracle Provider und der "richtige" ODP
)