1
OOP und Datenbankdesign
Moin Moin,
ich habe da mal eine kleine Frage bezüglich des Datenbankdesigns in objekt orientierten Programmiersprachen.
Also ich habe gerade damit begonnen, mich mit oop zu beschäftigen (c# bzw php).
Wenn ich jetzt eine oo Software schreiben möchte und eine Datenbankanbindung realisieren will, komme ich bei der Datenbankkonzeption eigentlich immer auf das gleiche Ergebnis wie bei der Klassenkonzeption.
Beispiel:
Ich möchte eine Software erstellen, wo man Kunden hat, die Geräte entleihen können.
Also erstelle ich eine Klasse Kunde. Der hat Eigenschaften (Name, Vorname, Anschrift usw).
Dann vielleicht noch eine Klasse Geräte. Hier gibt es Eigenschaften (Gerätenummer, Name, Standort...)
Wenn ich dann das DB Konzept mir dafür überlege, würde ich auch eine Tabelle Kunde mit den Eigenschaften und eine Tabelle Geräte mit dessen Eigenschaften erstellen.
Ich frage mich nur, ob das der richtige Weg ist, seine Daten zu speichern in einer Objekt orientierten Umgebung.
Weil wenn man dann mit den Daten arbeitet und diese dann immer in die Objekte speichert, dann sind die Eigenschaften der Objekte ja sozusagen nur ein Zwischenspeicher.
Wie würde man in einer OO Umgebung vorgehen, würde man bei starten des Programmes alle Datensätze als Objekte instanziieren, oder immer nur bei Bedarf nachladen?
Über ein paar Anmerkungen würde ich mich freuen.
mfg, brc
ich habe da mal eine kleine Frage bezüglich des Datenbankdesigns in objekt orientierten Programmiersprachen.
Also ich habe gerade damit begonnen, mich mit oop zu beschäftigen (c# bzw php).
Wenn ich jetzt eine oo Software schreiben möchte und eine Datenbankanbindung realisieren will, komme ich bei der Datenbankkonzeption eigentlich immer auf das gleiche Ergebnis wie bei der Klassenkonzeption.
Beispiel:
Ich möchte eine Software erstellen, wo man Kunden hat, die Geräte entleihen können.
Also erstelle ich eine Klasse Kunde. Der hat Eigenschaften (Name, Vorname, Anschrift usw).
Dann vielleicht noch eine Klasse Geräte. Hier gibt es Eigenschaften (Gerätenummer, Name, Standort...)
Wenn ich dann das DB Konzept mir dafür überlege, würde ich auch eine Tabelle Kunde mit den Eigenschaften und eine Tabelle Geräte mit dessen Eigenschaften erstellen.
Ich frage mich nur, ob das der richtige Weg ist, seine Daten zu speichern in einer Objekt orientierten Umgebung.
Weil wenn man dann mit den Daten arbeitet und diese dann immer in die Objekte speichert, dann sind die Eigenschaften der Objekte ja sozusagen nur ein Zwischenspeicher.
Wie würde man in einer OO Umgebung vorgehen, würde man bei starten des Programmes alle Datensätze als Objekte instanziieren, oder immer nur bei Bedarf nachladen?
Über ein paar Anmerkungen würde ich mich freuen.
mfg, brc
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 60814
Url: https://administrator.de/forum/oop-und-datenbankdesign-60814.html
Ausgedruckt am: 22.12.2024 um 23:12 Uhr
1 Kommentar
Ich würde sagen, es kommt auf Deine Datenbank an wie man es genau macht, wobei ich bisher noch nie mit einer echten OO Datenbank gearbeitet habe, nur mit relationalen Datenbanken.
Jedenfalls ist die Idee, beim Progarmmstart alle Daten als Objekte zu instanziieren die -zensiert- Idee, die man haben kann, wenn die DB mehr als 2 Datensätze hat.
Der Arbeitsspeicherverbrauch und die Zeit zum Anlegen der Objekte dürfte beidesmal gigantisch sein, weil es ist kein trivialer Task mal kurz 100000 Objekte anzulegen (und 100000 Datensätze sind nicht viel).
Bei relationalen Datenbanken als Speicher ist es, wie Du sagst, daß die Eigenschaften praktisch nur Zwischenspeicher für die Daten sind. Wobei ich dann es gleich so machen würde, daß das Kundenobjekt seine Eigenschaften direkt aus dem Recordset der Datenbank zieht.
Also keine Methode, die die Tabelle einliest und dann x Objekte erzeugt, die von dem Recordset getrennt sind, dann könnte es nämlich passieren, daß in der DB die Daten sich geändert haben, im Objekt noch nicht und das wars dann mit Datenkonsistenz.
Wie es Objekt-Orientierte Datenbanken machen, weiß ich nicht, habe noch nie eine gesehen.
Jedenfalls ist die Idee, beim Progarmmstart alle Daten als Objekte zu instanziieren die -zensiert- Idee, die man haben kann, wenn die DB mehr als 2 Datensätze hat.
Der Arbeitsspeicherverbrauch und die Zeit zum Anlegen der Objekte dürfte beidesmal gigantisch sein, weil es ist kein trivialer Task mal kurz 100000 Objekte anzulegen (und 100000 Datensätze sind nicht viel).
Bei relationalen Datenbanken als Speicher ist es, wie Du sagst, daß die Eigenschaften praktisch nur Zwischenspeicher für die Daten sind. Wobei ich dann es gleich so machen würde, daß das Kundenobjekt seine Eigenschaften direkt aus dem Recordset der Datenbank zieht.
Also keine Methode, die die Tabelle einliest und dann x Objekte erzeugt, die von dem Recordset getrennt sind, dann könnte es nämlich passieren, daß in der DB die Daten sich geändert haben, im Objekt noch nicht und das wars dann mit Datenkonsistenz.
Wie es Objekt-Orientierte Datenbanken machen, weiß ich nicht, habe noch nie eine gesehen.
