Datenbankzugriffe

morgen,

ich hoffe ihr könnt mir bei meinem kleinen Prob helfen...

Es betrifft das OO Design(egal in welcher Sprache) von Datenbankzugriffen. Und zwar ist es ja gang und gebe, ein z. B. eine Recordset- und eine Connectionklasse zu haben.

Nun aber zu meiner Überlegung: Macht es Sinn, für jede Tabelle ein spezialisiertes Recordsetobjekt von Recordset abzuleiten, was die Hauptfunktionalität von dem Recordset erbt, plus alle Zugriffe auf Felder, sowie SQL-Statements kapselt. Also, z. B. ne Tablle Kunde, hat z.B eine Klasse KundeDB. Alle anderen Klassen, die auf den Kunden zugreifen, machen dies über diese Klasse.

Mich würde mal Eure Meinung dazu interessieren ob so etwas Sinn macht?

Vielen Dank und noch nen schönen Nikolaus

Shade Of Mine

*nikolaus schrieb:

Mich würde mal Eure Meinung dazu interessieren ob so etwas Sinn macht?

und wenn die DB struktur gaendert wird?

Bei uns ist es so, dass eine Funktion nur einen bestimmten Teil der Tabelle kennt. zB verlangt die Funktion 'display', dass die Tabelle ein Feld ID und ein Feld Title hat. Was es sonst noch gibt, ist 'display' egal.

Willst du dafuer jetzt auch eine eigene Klasse definieren?

IMHO ist der Aufwand im vergleich zum Nutzen viel zu gross. Denn was genau waere der Vorteil?

danke für die schnelle Antwort...

Shade Of Mine schrieb:

und wenn die DB struktur gaendert wird?

Genau das dachte ich wär der Vorteil. So müsste ich nicht sämtliche Klassen nach den SQL-Satements absuchen, sondern habe sie zentral gekapselt.

Also z. B. eine Tabelle Kundem:

Kunde:
- id
- name
- weitere stammdaten

Dann hätte KundeDB Methoden wie, setId,setName,getId,getName,insert,delete usw.

Shade Of Mine schrieb:

IMHO ist der Aufwand im vergleich zum Nutzen viel zu gross. Denn was genau waere der Vorteil?

Genau das sind auch meine bedenken!

Also besser, in der Klasse wo bestimmte Daten benötigt werden, diese per SQL abfragen und nicht über eine eigene Klasse? (so hab ich das bisher immer gemacht, komme allerdings auch von C, daher solche Fragen zum elegenaten OO Design)

Gruss

Unix-Tom

Ich mache es nicht mit einer Klasse für jeden Table sondern mit einer Klasse für die DB und eine GET und SETfunktion für den Table.
Dadurch braucht man auch nur die Funktion ändern wenn sich ein Field im Table ändert.

Danke!

hättest Du vielleicht einen kleinen sample code, oder einen Link zu einem Beispiel wo es auf so eine Art gemacht wurde? Ich versteh zwar das Prinzip, aber an den Feinheiten grübel ich noch? Übergibst Du der set/get Methode den Feldindex?

Gruss

PS: Kennt einer von Euch ein gutes Opensource Projekt, welches mit Datenbanken arbeitet, wo Ihr der Meinung seit, dass es dort vorbildlich/elegant gelöst wurde?

Spacelord

*nikolaus schrieb:

....
PS: Kennt einer von Euch ein gutes Opensource Projekt, welches mit Datenbanken arbeitet, wo Ihr der Meinung seit, dass es dort vorbildlich/elegant gelöst wurde?

Ich beschäftige mich zur Zeit mit der postrelationalen Datenbank Cache.
Bei der definierst du dein Objekt(oder besser die Klasse dafür) mit einer Scriptsprache in der DB.
Die Proxyklassen für den C++ Zugriff werden von der DB generiert.Du kannst den Objekten in der Datenbank also getter/setter(oder was auch immer für) Methoden zuweisen und bei Änderungen an dem Objekt hat dass weitestgehend keinen Einfluss auf dein Anwendungscode.Du suchst in deiner Anwendung halt nach einem bestimmten Objekt und wie dieses Objekt nun genau aussieht wird in der DB festgelegt.
Das finde ich vorbildlich/elegant

PS:Die Bezeichnung postrelational hat die DB weil trotz Objektorientierung, Abfragen mit SQL möglich sind.

MfG Spacelord

danke, hört sich soweit auch gut an, aber wir sind erst vor kurzer Zeit auf postgres umgestiegen. Sind auch sehr zufrieden damit.

Gruss

AndreasW

hm,

Wenn man einfach eine allgemeine Kapselung der Daten in ein RecordSet implementiert, wird in den Anwendung (fast) direkt auf die Daten der Datenbank zugegriffen. Der direkte Kontakt mit der Datenstruktur der Datenbank weist in der Regel Probleme mit Änderungen auf der Datenbank auf. Wenn man zu Beispiel eine Tabelle ändert, kann man alle Anwendungen anpassen, wenn die Änderungen dieses erfordern. Dieses Problem versucht man in größeren Unternehmen durch effizientes Data-Warehousing zu umgehen.

es macht eigentlich durchaus Sinn eine Zwischenschicht in Form von Klaasen zu implementieren. Aber auch nur dann, wenn man wirklich Data-Warehousing mit einer 3 Tier- Architektur anstrebt.

Ziel dieses Konzeptes, ist die strikte Trennung der Visualisierung von der Datenbank. Es werden dabei aber nicht einfach die Tabellen in Klassen portiert. Viel mehr wird die Businesslogik, als ein Klassenframework abgebildet. Dieses Framework wird dann auf einem Applicationenserver zur Verfügung gestellt. Dabei stellt der Applicationserver alle Schnittstellen zur Verfügung, welche die visualisierenden Anwendungen benötigen. Das Programm läuft dann also auf dem Applicationserver und die Visualisierung findet dann über ein Thin-Client oder einer Web-Anwendung statt.

Nun ist es für die Anwendungen ziemlich egal, ob die Datenbank umgemodelt wird. Lediglich die Schnittstelle des Applicationservers muss angepasst werden. Die Anwendungen bleiben in der Regel dabei unangetastet.
Natürlich sind eventuell Erweiterungen und Änderungen notwendig, wenn die Geschäftslogik geändert wird. Dass ist aber ein nicht zu umgehendes Problem.

Vorteile, die dadurch entstehen:

- Zentralisierung des Geschäftsprozesses
- Einheitliche Geschäftsprossesse und Wiederverwendbarkeit von Teilprozessen
- Reduzierung der Komplexität und des Ressourcenbedarf der Anwendungen
- Echte Trennung der Daten von der Visualisierung und sicheres Controlling über den Applicationserver

Perfekt!

Ist zwar nicht für unseren Zweck geeignet, hat mir aber doch recht deutlich das Blickfeld für OO Programmierung in Bezug auf Datenbanken geöffnet!

Besten Dank!