Re: Datenstorage für einen Newsclient
Holger Boskugel
>> Hm... wenn es doch aber Abstraktionen wie ODBC (gibt f�r .NET sicher noch
>> Moderneres?) gibt, warum dann f�r jede DB spezifische Implementierungen?
>> Wenn man das auf der gr�nen Wiese aufsetzt, dann w�hlt man doch ein
>> Datenmodell, dass sich auf allen RDBMS nutzen l�sst.
>> Oder besser gleich einen OR-Mapper verwenden, gibt's doch jetzt auch in
>> .NET - oder?
Bez�glich ODBC habe ich das nur als Beispiel aufgef�hrt, damit nat�rlich
eine
schon bereits recht offene DB.Schnittstelle benutzt, die aber einige
Nachteile
hat in bezug auf Performance. So habe ich deutliche Unterschiede zwischen
SQLClient, Odbc und OleDb in einem Projekt feststellen m�ssen bei denen
die Verh�ltnisse 1:15:20 waren. Somit sich also anbietet eine eigene
DB-Schnitt-
stelle zu nutzen �ber die man seine Daten schiebt um ggf.
Perfomance-Vorteile
mitzunehmen.
Klar ist auch dass jede der spezifischen Verbindungsobjekte auch schon bei
Microsoft eine neutraleres Interface implemententiert aus System.Data.Common
(siehe R�ckgabe aus meiner Methode GetThreadsHeaders()). Doch diese
Abstraktion reicht in dem Sinne nicht aus wenn es um die Parametrierung von
Queries geht (DbCommand.Parameters). Da sind nun mal die Typenspezifischen
Parameter Konfigurationen zu setzen.
> Die SQL-Dialekte sind ja nicht gleich und nicht jede DB kann alles was
> andere k�nnen, allein das m�sste man abfangen.
Hat Ullrich Recht, hier liegt noch mal ein grosses Potential Vorteile der
jeweiligen
DB f�r die Anwendung zu nutzen. So hab ich 2005 live miterleben d�rfen wie
ein ORACLE Profi meine f�r SQL-Server und ORACLE passenden Queries
in ORACLE so angepasst hat das die Performance bis zum Faktor 10 besser
war. Da ORACLE einen Unterchied macht bei JOINs in ANSI-Notation oder
fr�heren Where-Klauseln. Zum anderen nutzt ORACLE bestimmte nicht ANSI
konforme Kommentare um weitere Perfomance-Einstellungen zuzulassen. Auch
der SQL-Server bietet da einige Optionen, die nicht zwischen den DB-Systemen
zu �bertragen sind.
> Die DB-Provider von .Net haben nat. auch ein Interface implementiert, aber
> auch da ist vieles von den Klassen her, schon nicht kompatibel.
Nun soweit, wie schon beschrieben die Klassen auf den Interfaces aus dem
Namespace System.Data.Common aufsetzen sind sie in einem gewissen Ma�e
austauschbar, eine Einschr�nkung erw�hnte ich oben schon.
> Aber ob sich Aufwand lohnt ein Interface auszuarbeiten, nur weil jemand
> vielleicht mal na andere DB haben will?
Gut dar�ber l�sst sich schreiten oder philosophieren. Das ist nun mal nach
dem
Geschmack jedes einzelnen. Meine Erfahrung darin ist allerdings, je eher ich
im
Design-Prozess neutrale Elemente einsetze je besser bin ich sp�ter dran die
nach Kundenw�nschen gestalteten Anpassungen zu realsieren. Und zum anderen
war bereits angesprochen, dass die Software mit dem Framework.NET und
auch mit Mono laufen soll und haben wir nun mal einen ganzen Set
unterschied-
licher Datenbanken. Auch allein wenn ich seh, den Einsatz von
File-orientierten
(-Desktop)Datenbanken wie MSAccess, dBase/FoxPro oder SQLite oder
Serverbasierten der Art MS-SQL(-Express), ORACLE etc. Von daher kann
es ganz schnell sein, dass sich der Aufwand lohnt und ggf. sogar der Kunde
selbst in der Lage ist sich die passende Schnittstelle zu seiner DB
programmieren
zu lassen.
Viele Gr�sse
Holger