Datenhaltungs-Problem

[Philipp Hasenfratz]

Halihallo Andreas

noch 'n bissle mehr... ;)

Ich überlege mir gerade eine Datenstruktur für die Objekt-Datenbank eines Immobilien-Maklers. Das Problem, es handelt sich um verschieden Immobilen-Arten. Das sind zum einen normale Einfamilienhäuser, Wohnungen, aber auch Ferienhäuser(im Ausland), alles jeweils als Kaufobjekt, aber auch als Mietsobjekt. Das Problem ist, das je nach Typ andere Daten relevant sind. Für Einfamilienhäuser ist es beispielweise die Strasse und Wohngegend, bei Ferienhäusern ist dagagen das Land, und die Ferienregion interessant. Bei Mietobjekten kommen andere Dinge dazu, wie Miete, Nebenkosten... das sind noch viel mehr Dinge die mir aber gerade nicht einfallen.

Jetzt wirds noch komplizierter ;-)
Also aus Sicht der Datenbankmodellierung würde das dann so aussehen:

Ferienhaus
                |
               ISA
              /   \              /     \          FHMiete  FHKauf

und das selbe für alle anderen zwei Typen von Immobilien, d. h. du hast dann (s. anderes
Postings) eine Tabelle Tbl_Immobilien, Tbl_Ferienhaus und jetzt kommen noch zwei
dazu: Tbl_Ferienhaus_Miete, Tbl_Ferienhaus_Kauf, beide mit PrimaryKey immobilien_id
über einen JOIN kannst du die Relevanten Daten aller drei Relationen (Tbl_Immobilien,
Tbl_Ferienhaus, Tbl_Ferienhaus_?) erhalten und du hast keine Redundanten Informationen
im Schema (anders bei deinem Vorschlag, alles in eine Tabelle stecken). Natürlich ist
der Aufwand dadurch grösser, aber andernfalls geht es auf Kosten der Datenintegrität.

Da demnächst eine "Runderneuerung" der Homepage ansteht, wollte ich mir mal ein besseres Konzept für die Datenhaltung überlegen, welche dann auch mit einer einzigen Version der Homepage klarkommt. Dazu sollen Mietobjekte in die Datenbank aufgenommen werden.

Das System müsste "einfach" auf den Typ der Immobilie reagieren, handelt es sich bei
immobilien_id = ??? um ein Ferienhaus, Einfamilienhaus, ... dazu, welcher "sub-typ"?
Miete oder Kauf?

Und jetzt weiß ich nicht ob es das beste ist, die Feldbezeichnungen der Objekttabelle in einer anderen Tabelle zu speichern, und dann in der Objekttabelle(für alle Objekte) nur noch sowas speichern:

[...dein DB-Entwurf...]

so ginge es auch, obgleich das Schema nicht mehr das Schema ist und vom Anwenderprogramm
gesetzt wird (was eigentlich nicht umbedingt sein soll). Das Schema (Attribute, Werte),
sollten eigentlich durch die DB charakterisiert sein.

Ok, ich könnte für jeden Feld-Typ ein Feld in die Objekt-Tabelle machen und nur das passende Feld verwenden und diese Information in der Feld-Tabelle mitspeichern, was haltet ihr hiervon?

Nicht sehr schon im Sinne der Modellierung, aber vollständig Funktional. Ich würde jedoch
eher den Weg über die ISA-Konstruktion gehen, denn diese ist etwas "logischer". Zudem
dürfte sich der Arbeitsaufwand etwa auf das selbe belaufen.

Ist es am Ende nicht doch besser alle Felder die insgesamt möglich sind in die Objekt-Tabelle zu schreiben, dazu den Objekttypen, und beim schreiben der Daten halt ein Formular anzubieten womit man entsprechend dem Objekttyp nur die notwendigen Felder ausfüllt?

Nein, bitte nicht ;)
Da speicherst du ja unmengen irrelevanter Daten! - Beispiel: Du verwaltest ein
Einfamilienhaus, und musst notgedrungen alle Felder für Ferienhäuser etc. auf NULL
setzen; diese NULL's brauchen aber auch Speicherplatz, wie du weisst.

Wie würdet Ihr das machen? Worauf muß man vielleicht bzgl. möglichen Erweiterungen, Portabilität der Daten... noch achten?

Erweiterungen und Portabilität ist durch deinen und meinen Vorschlag nicht
ausgeschlossen. Hauptsache unabhängige Daten sind auch unabhängig modelliert, dann ist
das System erweiterungsfähig. => noch ein Fakt, warum das "alles in einer Tabelle
speichern" keine vernünftige Lösung ist.

Viele Grüsse und HTH

Philipp