DB-System

[Andy_DB]

Hallo Client Server Experten,

Ich möchte unsere Software, Datenbankmässig universell machen.
Was heisst das ?
Es ist doch so, dass die Kunden entweder MSSQL, Oracle, DB2 usw. sich wünschen weil diese sich eben ein solches System angeschafft haben.
Der jeweilige Admin kennt sein System u. möchte dabei bleiben.
Nun , wie kann dem Rechnung getragen werden ?
Da "schönste" wäre SQL-Delphi-Komponenten, in der das Zielsystem konfiguriert werden könnte.
Klar, dass man dann dabei nicht immer die 100%ige Performance erwischt bzw. die speziellen Vorteile des installierten DB-System erreicht. Man kann eben nicht alles haben...

Wer kann mir da ein Tip geben ?

Andy

[Bernhard Geyer]

Fertige Lösungen für sowas wären das ECO-Framework oder NHypernate.
Ansonsten scahu dir es Bridge-Pattern an und mach es selbst.

SQL-Komponenten können sowas nicht leisten da sie nicht dafür ausgelegt sind die SQL-Syntax zu normen.

[Andy_DB]

Danke Bernhard,

Du bist anscheinend der einzige Experte hier.
Ich habe eine sämtliche Homepages angesehen und vielleicht eine Lösung gefunden, nämlich: Core Lab !

Da die Komponenten in sich sehr ähnlich sind, denke ich daran die Komponenten im "Bridge pattern" Prinzip zu kapseln.
Was meint Ihr dazu ?
Ja Ihr, ich will nicht ausschliesslich den aktiven Bernhard belasten.
Wer hat praktische Erfahrung mit diesen Komponenten ?

Andy

[Bernhard Geyer]

Core Labs kompos sind schon sehr gut (Verwende die für MySQL) aber können das Problem mit den SQL-Dialekt-Unterschieden auch nicht lösen bzw. wollen es auch gar nicht.

[hwoess]

An Andy - ein einfaches Beispiel: in Oracle, MySQL, DB2 gibt es den Datentyp DATE, beim SQL-Server derzeit noch nicht (kommt mit SQL2008) - das hat nicht nur Auswirkung auf das Table-Create sondern auch auf alle Programmteile, wo dieses Feld verwendet wird. Oder wenn man sich die Datums- oder Stringfunktionen ansieht, da gibt es eigentlich keinen Standard. Das Wissen, wie man was in welcher Datenbank löst, kann dir keine Komponente abnehmen. Wenn du annimmst, einmal ein SQL-Statement zu schreiben und das dann auf X Datenbanken ausführen zu können, dann irrst du dich leider gewaltig. CoreLab übernimmt dabei nur den Part des Zustellers, um das Statement an eine beliebige (von Corelab unterstützte) DB zu schicken, aber ob die dann das Statement auch versteht ist wieder etwas ganz anderes.

bye,
Helmut

[Andy_DB]

Bernhard und Helmut.
ich verstehe euch und ihr habt absolut Recht.
Aber wir sind ja Developer, also wo bitte soll das "unlösbare" Problem sein ?
Das kleines Beispiel vom Helmut:
Ich kreiere ein DB-Objekt wo als property das aktive SQL-System konfiguriert ist.
Also wenn das Zielsystem "SQL-Server" kein "DATE" kennt, dann würde ich es als "FLOAT" speichern wollen und wenn es dann das andere ist eben doch als "DATE".
Das interne Datenformat würde ich auf keinen Fall ändern, also muss die Struktur als Speicherblock bzw. Speichergrösse immer dieselbe sein.
Und da sind wir beim polymorphen Objekten angelangt womit wir jeden Tag arbeiten.
Klar es ist Arbeit, aber so liesse sich jedes SQL-System portieren.
Ich wundere mich darüber, dass dies noch keiner gemacht hat, deshalb meine Nachfrage in diesem Forum.
Jetzt geht es mir darum wie ich das lösen kann, dass das Zielsystem beim Kunden nicht alle möglichen Client-Treiber installiert haben muss, sondern wirklich nur seins.
Dabei wird man wohl auf DLL's ausweichen müssen.
.NET wäre ein toller Ansatz, aber Delphi ist auch noch nicht soweit.
So bin ich auf konstruktive Diskussionen angewiesen u. ich denke genau dafür ist das Forum da.

Also ihr lieben SQL-Leute, was fällt euch noch ein ?

Andy

[Bernhard Geyer]

Es ist kein unlösbares Problem. Unsere Firmen-Hauptanwendung unterstützt mehrere DB's indem wir ein Bridge-Pattern realisiert haben und damit alle DB-Unterschiede gekapselt haben (Bei Oracle muss man sogar durch das Bridge-Pattern versuchen die nicht gerade wenigen Implementierungsfehler der DB zu kapseln). Für MySQL und MS SQL-Server brauchen wir keinerlei Extra Installation mehr und bei Firmen mit Oracle im Einsatz ist das Problem auch schon immer von der IT gelöst. Der Hauptaufwand weitere DB's zu unterstützen wäre mehr im Bereich des internen Know-How-Aufbaus zu suchen (Man wird manchmal als DB-Admin-Ersatz "mißbraucht".

.NET bringt von Haus aus auch keine Lösung da die SQL-Dialekt-Unterschiede ja auch nicht gekapselt werden. Auch MS will ja es dem Entwickler nicht zu einfach machen das die eingesetzte DB einfach zu wechseln ist. Man setzt auch voll auf das Vendor Login-Antipattern. Vorteil von .NET ist das es hier schön Datasets gibt die nicht DB-Gebunden sind. Aber genau solche Objekt (in nicht so mächtiger Ausführung) haben wir selbst unter Delphi.Win32 selbst entwickelt.

[Andy_DB]

Deinen Ausführungen stimme ich voll und ganz zu.
Danke dir nochmals Bernhard für deine Infos und ich denke diesen Thread können wir somit schliessen.

Andy