Hallo

ich soll eine C#-Applikation schreiben, die vorerst einmal auf eine
MySQL-Datenbank zugreiffen soll; was sich aber in einem bis zwei
Jahren ändern wird, und dann soll diese Applikation mit einem SQL-
Server zusammenarbeiten.

Frage an die Profis hier: wie würdet Ihr eine solche Applikation
beginnen, um nach der Datenbank-Umstellung möglichst wenig (oder gar
keinen) Programmier-Aufwand zu haben - die gleiche Applikation mit
der gleichen Datenbank-Struktur weiter zu verwenden.....

Danke schon mal für Infos dazu
Schönen Gruß
Michael

Michael Erlinger schrieb:

> ich soll eine C#-Applikation schreiben, die vorerst einmal auf eine
> MySQL-Datenbank zugreiffen soll; was sich aber in einem bis zwei
> Jahren ändern wird, und dann soll diese Applikation mit einem SQL-
> Server zusammenarbeiten.
>
> Frage an die Profis hier: wie würdet Ihr eine solche Applikation
> beginnen, um nach der Datenbank-Umstellung möglichst wenig (oder gar
> keinen) Programmier-Aufwand zu haben - die gleiche Applikation mit
> der gleichen Datenbank-Struktur weiter zu verwenden.....

Ist relativ unwahrscheinlich, dass man gar keinen Aufwand mehr hat.
Ebenso unwahrscheinlich ist, dass sich die DB-Schemata auf's Haar
gleichen. I.d.R gibt es da ein paar Feinheiten, z.B. beim
Datentyp-Mapping. MySQL hat z.B. afaics kein wirkliches bool
bzw bildet das intern als irgendein speziellen mini-int-Typ ab,
der in ADO.NET als sbyte gemappt wird.
MS-SQL unterstützt aber schon bool und .NET mappt das auch wie
erwartet und da fängt es dann schon an...


Es empfiehlt sich natürlich die Connection- und andere -Parameter
in config-files auszulagern, dann bleibst Du auf dieser Ebene
schon mal flexibel.

Die Standard-Herangehensweise bzgl Klassenlayout sieht oft wie folgt
aus:

1. Traditionelle Herangehensweise (ADO.NET)
Zwei Datenzugriffsklasse, die jeweils als Intefaces abstrahiert
werden und für jedes RDBMS eine Implementation erfahren.
- Eine für grundlegende Datenzugriffe wie Connection aufbauen, SPs
ausführen und Daten zurückgeben bzw manipulieren, Transaktionskontexte
etc.

- Eine weitere, das eigentliche DAL, für die konkreten
Anwendungsspezifischen DB-Zugriffe kapselt und ausführt und die
intern die erstere verwendet. Wenn Du es richtig und gut machst, musst
Du diese Klasse nur einmal implementieren, weil alle DB-Spezifika
bereits von Klasse 1 abgefangen werden.

- DB-seitig möglichst alle Zugriffe über Stored-Procs
abfrühstücken, selbst trivialste SELECT *'s, so dass möglichst kein
SQL im Code vorkommt und außerdem alle Parameter typisierbar sind.
Benamsung von SPs und allen DB-Objekten möglichst ASCII,
unexotisch und nach nachvollziehbarem, übertragbarem Schema.
SP-Innereien eher schlicht halten im Hinblick auf Portierbarkeit.


Um trendy zu sein und im Windschatten des aktuellen Hypes und
auf der weiten See der Buzzwords zu segeln, kann man es mit
Object Relationalem Mapping versuchen:
Kapsle alle Datenbankzugriffe mit Hilfe eines ORM-Tools wie ADO-Entities
NHibernate oder Genome. Wirf SQL über Bord und lerne stattdessen HQL
oder eSQL und wie man Mapping-Dateien editiert, konzentriere dich
ansonsten auf OO und achte Performanceaspekte gering - sonst hast Du mit
ORM nicht immer Freude ;-) )

Gruß
Christoph

Hallo Christoph

danke vorweg einmal für die ausführlichen Infos. Natürlich ergeben
sich dadurch noch einige Fragen, die sicherlich den Rahmen hier
sprengen würden - aber eine muss ich Dir trotzdem nochmals stellen:

> - DB-seitig möglichst alle Zugriffe über Stored-Procs
> abfrühstücken, selbst trivialste SELECT *'s, so dass möglichst kein
> SQL im Code vorkommt und außerdem alle Parameter typisierbar sind.
> Benamsung von SPs und allen DB-Objekten möglichst ASCII,
> unexotisch und nach nachvollziehbarem, übertragbarem Schema.
> SP-Innereien eher schlicht halten im Hinblick auf Portierbarkeit.

Alle Abfragen über StoredProc. -> meinst Du damit auch eine "einfache"
Abfrage wie zum Beispiel <SELECT * from MyTable> - die mir die
komplette TabellenStruktur und alle Daten zurückliefert, auf die ich
dann zum Beispiel über eine DataAdpater die INSERT/UPDATE/DELETE-
Commands aufbauen kann ?
und wenn ich dann komplexere Abfragen benötige - ebenfalls jede
Abfrage in eine eigene StoreProc. packen ?
und wie meinst Du das mit "alle Parameter typisierbar sind" ??

Danke nochmals & schönen Gruß
Michael

Hallo,

Michael Erlinger schrieb:
> Hallo Christoph
>
> danke vorweg einmal für die ausführlichen Infos. Natürlich ergeben
> sich dadurch noch einige Fragen, die sicherlich den Rahmen hier
> sprengen würden - aber eine muss ich Dir trotzdem nochmals stellen:
>
>> - DB-seitig möglichst alle Zugriffe über Stored-Procs
>> abfrühstücken, selbst trivialste SELECT *'s, so dass möglichst kein
>> SQL im Code vorkommt und außerdem alle Parameter typisierbar sind.
>> Benamsung von SPs und allen DB-Objekten möglichst ASCII,
>> unexotisch und nach nachvollziehbarem, übertragbarem Schema.
>> SP-Innereien eher schlicht halten im Hinblick auf Portierbarkeit.
>
> Alle Abfragen über StoredProc. -> meinst Du damit auch eine "einfache"
> Abfrage wie zum Beispiel <SELECT * from MyTable> - die mir die
> komplette TabellenStruktur und alle Daten zurückliefert, auf die ich
> dann zum Beispiel über eine DataAdpater die INSERT/UPDATE/DELETE-
> Commands aufbauen kann ?

gerade Stored Procedures versuchen wir bei einfachen Abfragen vollkommen
zu vermeiden. Bei einfachen Abfragen sind SPs eigentlich überflüsig und
bei komplexen Abfragen unterscheiden sich die SQL Dialekte doch erheblich.

Wir benutzen XPO von DevExpress als OR Mapper, für > 95% aller
Standardoperationen reicht das vollkommen aus. Den Rest kann man dann in
Stored Procedures verpacken. Der OR Mapper kann sowohl mit MySQL (warum
überhaupt MySQL und kein richtiges DMBS wie PostgreSQL?) als auch mit
dem SQL Sever und noch mit vielen anderen umgehen.

> und wenn ich dann komplexere Abfragen benötige - ebenfalls jede
> Abfrage in eine eigene StoreProc. packen ?
> und wie meinst Du das mit "alle Parameter typisierbar sind" ??

Gruß

Klaus

"Michael Erlinger" <michael.erlinger*hotmail.com> schrieb

> ich soll eine C#-Applikation schreiben, die vorerst einmal auf eine
> MySQL-Datenbank zugreiffen soll; was sich aber in einem bis zwei
> Jahren ändern wird, und dann soll diese Applikation mit einem SQL-
> Server zusammenarbeiten.

> Frage an die Profis hier: wie würdet Ihr eine solche Applikation
> beginnen,

Garnicht - der Aufwand ist enorm und alle Versuche bisheriger Firmen
kläglich gescheitert.

Solche Versuche zeugen auch von der Ahnungslosigkeit der Entscheider. Wer
sowas verlangt und versucht gilt bei mir schonmal als ahnungsloser Idiot.

Michael Erlinger wrote:

> Hallo
>
> ich soll eine C#-Applikation schreiben, die vorerst einmal auf eine
> MySQL-Datenbank zugreiffen soll; was sich aber in einem bis zwei
> Jahren ändern wird, und dann soll diese Applikation mit einem SQL-
> Server zusammenarbeiten.
>
> Frage an die Profis hier: wie würdet Ihr eine solche Applikation
> beginnen, um nach der Datenbank-Umstellung möglichst wenig (oder gar
> keinen) Programmier-Aufwand zu haben - die gleiche Applikation mit
> der gleichen Datenbank-Struktur weiter zu verwenden.....

Einfach: O/R Mapper ausprobieren und schauen welcher geeignet ist, zum
Beispiel:

* NHibernate
* Entity Framework

Später muss (im Idealfall) nur noch die Datenbank in der Konfiguration
umgestellt werden.

Wenn man schon weiss welche Datenbank später eingesetzt werden soll kann
man das auch bei Entwicklung und Tests berücksichtigen um die Feinheiten
der Systeme kennenzulernen. Hat man erst mal den Bogen raus, geht es mit
den nächsten RDMS entsprechend einfacher.

Viele Grüße,
--
Michael Justin
SCJP, SCJA
betasoft - Software for Delphiâ„¢ and for the Javaâ„¢ platform
http://www.mikejustin.com - http://www.betabeans.de

Hallo Michael,

> ich soll eine C#-Applikation schreiben, die vorerst einmal auf eine
> MySQL-Datenbank zugreiffen soll; was sich aber in einem bis zwei
> Jahren ändern wird, und dann soll diese Applikation mit einem SQL-
> Server zusammenarbeiten.
> Frage an die Profis hier: wie würdet Ihr eine solche Applikation
> beginnen, um nach der Datenbank-Umstellung möglichst wenig (oder gar
> keinen) Programmier-Aufwand zu haben - die gleiche Applikation mit
> der gleichen Datenbank-Struktur weiter zu verwenden.....

Stored Procs würde ich vermeiden.
Für unabhängige DB-Entwicklung würde ich
als eine Möglichkeit den DbProviderFactory in Betracht
ziehen, allerdings würde ich beim Datenbank-Design
darauf achten, dass möglichst allgemeingültige Typen
benutzt werden, quasi als GGT.

[DbProviderFactory-Klasse (System.Data.Common)]
http://msdn.microsoft.com/de-de/libr...erfactory.aspx

[ADO.NET DbProviderFactory and.... - Stack Overflow]
http://stackoverflow.com/questions/1...derfactory-and
________

Eine andere Möglichkeit wären die OR-Mapper, würde ich
das Entity Framework empfehlen würde, allerdings würde ich
da, wenn möglich schon versuchen, mit dem EF des VS
2010 Beta2 (das feature-complete, aber noch nicht Bug-frei ist)
zu beginnen, je nach Zeitrahmen, denn es
gibt ein paar vorteilhafte Zusatzfeatures.

[Einführung in Entity Framework]
http://msdn.microsoft.com/de-de/library/bb399567.aspx

Neu in Version 2 ist beispielsweise, dass Änderungen der
Datenbankstruktur einfach auf den Anwendungscode übertragen werden
können. Weiterhin ist die Unterstützung für die modellgetriebene
Entwicklung neu: Es ist nun erstmals auch die Generierung der
Datenbank aus dem Entitymodell möglich, dadurch lässt sich die
Entwicklungsdauer datengetriebener Anwendungen stark verkürzen und die
Pflege der Anwendungen vereinfachen. Auch ein anpassbarer Wizard für
die Codegenerierung ist vorhanden: im neuen Entity Framework v2 können
Entwickler nun den vom Wizard zu generierenden Quellcode selbst
bestimmen. Die Standard-Codegenerierung wird in Form von T4 Text-
Templates ausgeliefert und kann von jedem Entwickler individuell
angepasst werden. Persistence-Ignorant Objects erlauben es
Entwicklern, individuelle Datenklassen mit dem Datenmodell zu
verwenden, ohne von "Entity"-Klasse erben zu müssen.

[Generating Artifacts By Using Text Templates]
http://msdn.microsoft.com/en-us/libr...5(VS.100).aspx


ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET

Hallo Michael,
> Frage an die Profis hier: wie würdet Ihr eine solche Applikation
> beginnen, um nach der Datenbank-Umstellung möglichst wenig (oder gar
> keinen) Programmier-Aufwand zu haben - die gleiche Applikation mit
> der gleichen Datenbank-Struktur weiter zu verwenden.....

neben den rein technischen Tipps, die hier schon gepostet wurden, noch
ein organisatorischer Tipp: warte nicht erst ein bis zwei Jahre ab,
bevor du die DB wechselst, sondern setz' möglichst bald auch dein
zweites Zielsystem in einer Testumgebung auf, welches du gelegentlich
immer mal wieder ausprobierst. So vermeidest du später böse
Überraschungen, auf was du alles hättest achten müssen.

Grüße

- Michael -