DB-Design und OOP

Ich möchte mir allgemein nutzbare Klassen bauen, deren Objekte in einer
Datenbank gespeichert werden. Nun bin ich mir nicht sicher, wie ich die
Erweiterung von Klassen am besten in mein DB-Design übertragen kann.

Hier mal ein Beispiel, was ich meine:

class UploadedFile
{
protected $filename = '';
protected $filetype = '';
protected $filesize = 0;

public function create()
{
// Datenbankeintrag erstellen
}

public function update()
{
// Datenbankeintrag aktualisieren
}

public function destroy()
{
// Datenbankeintrag löschen
}
}

class Image extends UploadedFile
{
protected $width = 0;
protected $height = 0;

public function create()
{
}

public function update()
{
}

public function destroy()
{
}
}

Jetzt könnte ich mit einer einzigen Tabelle arbeiten:
oop_files:
id_file int
filename varchar(255)
filetype varchar(255)
filesize varchar(255)
width int
height int

Vorteil:
Einfache Queries

Nachteile:
Normale Dateien haben keine width- und height-Werte, die Spalten sind
unnütz.
Ich muss die Funktionen create() und update() komplett überschreiben,
mir müssen die Eigenschaften übergeordneter Klassen bekannt sein, und
wenn ich diese ändere, muss ich alle erbenden Klassen ändern. (Ok, das
ließe sich noch mit einem Array umgehen)

Oder ich habe für jede Klasse eine Tabelle mit den zugehörigen
Eigenschaften:
oop_files:
id_file int
filename varchar(255)
filetype varchar(255)
filesize varchar(255)

oop_images:
id_image int
id_file int
width int
height int

Vorteil:
Ich muss bei Erweiterung nur immer die parent::Methoden aufrufen.
Kein unnützer Datenoverhead.

Nachteile:
Alle Eigenschaften eines Image-Objekts erhalte ich nur mit einem JOIN.
SELECT * FROM oop_images AS t1 LEFT JOIN oop_files AS t2 USING id_file


Welche Methode würdet ihr bevorzugen oder würdet ihr ganz anders an die
Sache rangehen?

Soll ich den Datenoverhead von Methode 1 zugunsten der besseren
Performance ignorieren? Meine innere Stimme sagt mir Ja, aber ich bin
nicht sicher. Wenn noch mehr Klassen von UploadedFile erben, wächst
schließlich auch der Overhead. Könnte das die Performance wiederum
negativ beeinflussen, auch wenn man kein SELECT * verwendet?

Gruß, Hendrik

Re: DB-Design und OOP

Hendrik Pilz schrieb:

> Jetzt könnte ich mit einer einzigen Tabelle arbeiten:
>
> Vorteil:
> Einfache Queries
>
> Nachteile:
> Normale Dateien haben keine width- und height-Werte, die Spalten sind
> unnütz.
> Ich muss die Funktionen create() und update() komplett überschreiben,
> mir müssen die Eigenschaften übergeordneter Klassen bekannt sein, und
> wenn ich diese ändere, muss ich alle erbenden Klassen ändern. (Ok, das
> ließe sich noch mit einem Array umgehen)

Schlecht.

> Oder ich habe für jede Klasse eine Tabelle mit den zugehörigen
> Eigenschaften:
>
> Vorteil:
> Ich muss bei Erweiterung nur immer die parent::Methoden aufrufen.
> Kein unnützer Datenoverhead.
>
> Nachteile:
> Alle Eigenschaften eines Image-Objekts erhalte ich nur mit einem JOIN.
> SELECT * FROM oop_images AS t1 LEFT JOIN oop_files AS t2 USING id_file
>
> Welche Methode würdet ihr bevorzugen oder würdet ihr ganz anders an die
> Sache rangehen?

Ich arbeite mit letzterer Methode. JOINs sind nict schlimm.

MfG
Niels

--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · E-Commerce · Mambo Content Management |
------------------------------------------------------------ ----

Re: DB-Design und OOP

Niels Braczek wrote:
> Hendrik Pilz schrieb:
>
>
>>Jetzt könnte ich mit einer einzigen Tabelle arbeiten:
>>
>>Vorteil:
>>Einfache Queries
>>
>>Nachteile:
>>Normale Dateien haben keine width- und height-Werte, die Spalten sind
>>unnütz.
>>Ich muss die Funktionen create() und update() komplett überschreiben,
>>mir müssen die Eigenschaften übergeordneter Klassen bekannt sein, und
>>wenn ich diese ändere, muss ich alle erbenden Klassen ändern. (Ok, das
>>ließe sich noch mit einem Array umgehen)
>
>
> Schlecht.
>
Wieso? Wegen dem Overhead?
>
>>Oder ich habe für jede Klasse eine Tabelle mit den zugehörigen
>>Eigenschaften:
>>
>>Vorteil:
>>Ich muss bei Erweiterung nur immer die parent::Methoden aufrufen.
>>Kein unnützer Datenoverhead.
>>
>>Nachteile:
>>Alle Eigenschaften eines Image-Objekts erhalte ich nur mit einem JOIN.
>>SELECT * FROM oop_images AS t1 LEFT JOIN oop_files AS t2 USING id_file
>>
>>Welche Methode würdet ihr bevorzugen oder würdet ihr ganz anders an die
>>Sache rangehen?
>
>
> Ich arbeite mit letzterer Methode. JOINs sind nict schlimm.
>
Schreibst du die JOINs alle von Hand oder kannst du sie dynamisch zur
Laufzeit generieren lassen?

Gruß, Hendrik

Re: DB-Design und OOP

Hendrik Pilz schrieb:
> Niels Braczek wrote:
>> Hendrik Pilz schrieb:
>>
>>>Jetzt könnte ich mit einer einzigen Tabelle arbeiten:
>>
>> Schlecht.
>>
> Wieso? Wegen dem Overhead?

Es verträgt sich 1. IMHO nicht mit wirklich mit dem OOP Paradigma und 2.
verstößt es gegen die Normalisierung der Datenbank. Daten, die nur von
einigen Datensätzen gebraucht werden, gehören in eine eigene Tabelle.

>>>Oder ich habe für jede Klasse eine Tabelle mit den zugehörigen
>>>Eigenschaften:
>>
>> Ich arbeite mit letzterer Methode. JOINs sind nicht schlimm.
>>
> Schreibst du die JOINs alle von Hand oder kannst du sie dynamisch zur
> Laufzeit generieren lassen?

Ich schreibe sie idR einmal von Hand: in die Load-Funktion der
Model-Klasse. Allerdings kann das manchmal auch etwas knifflig werden,
wenn eine solche Klasse mit anderen so verknüpft wird, dass weitere
JOINs erforderlich werden. Dann kommt man kaum darum herum, das Ganze
mit einem QueryBuilder (zB PEAR::DB) aufzubauen.

MfG
Niels

--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · E-Commerce · Mambo Content Management |
------------------------------------------------------------ ----

Re: DB-Design und OOP

Hendrik Pilz wrote:
> Ich möchte mir allgemein nutzbare Klassen bauen, deren Objekte in einer
> Datenbank gespeichert werden. Nun bin ich mir nicht sicher, wie ich die
> Erweiterung von Klassen am besten in mein DB-Design übertragen kann.
[...]
> oop_images:
> id_image int
> id_file int
> width int
> height int

Bei dieser Tabelle solltest du die image id weg lassen, die file id
reicht total aus um den Datensatz eindeutig zu definieren.

>
> [...]
> Gruß, Hendrik

Gruß
Manuel