Lude: Datenhaltungs-Problem

Beitrag lesen

Hi,

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.

bisher vermute ich also, dass die DB 'OBJEKTE' mehrere Tabellen wie z.B. 'EINFAMILIENHAEUSER' oder auch 'FERIENHAEUSER' beinhaltet. - Du bist etwas ungluecklich, weil Du meinst den realen Sachverhalt nicht optimal abgebildet zu haben.

Bisher hatte ich das(Altlast, Access...;-)) immer getrennt, Mietobjekte waren gar nicht in der Datenbank, lokale Objekte hatten jeweils eine eigene Tabelle für Objekte, Anbieter, Interessenten, und Ferienimmobilen wurden entsprechend für jedes Land(es sind nur 2) in eigenen Tabellen verwaltet.

Also es ist eine "verteilte" Datenhaltung mit verschiedenen Datenhaltungen. (Das macht Dich nicht gluecklicher.)

Das hatte ich mir mal vor einiger(!) Zeit überlegt, was mich aber langsam vor größere Probleme stellt, vor allem da ich damals für alle 3 Themengebiete(lokal, land1, land2) eine eigene Homepage gebastelt habe, die zwar alle gleich aussehen, aber voneiander unabhängig waren. Und jedesmal wenn ich jetzt was ändern muß ist das der Aufwand x 3, ganz zu schweigen von den Problemen in der Datenhaltung.

Eine typische Konsequenz des o.g. Sachverhalts.

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.

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:

Objekt_ID | Feld_ID | Wert
----------+---------+---------
1         | 1       | 320000
1         | 6       | Goethestrasse 45
...
2         | 2       | 400
...

dann eine extra Tabelle mit

Objekt_ID | Objekt_typ
----------+------------
1         | Einfamilienhaus
2         | Mietwohnung
...

und dann noch:

Feld_ID | Feld-Bezeichnung
----------+------------
1       | Kaufpreis
2       | Monatsmiete
...
6       | Strasse
...

Eine Todsuende! - Allerdings nicht ohne Charme.

Aber das schmeckt mir im Prinzip überhaupt nicht. Denn es gibt auch Text-Felder mit möglicherweise einigen KB Text. Ich kann ja schlecht alles in soche Blob-Felder schreiben.
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?

s.u.

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? Ich denke so sollte man das machen, oder hat hier jemand eine bessere Idee?

Schon besser. s.u.

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

Warum ich frage liegt vor allem daran, das ich damals auch davon überzeugt war das das so und nur so am besten ist, so einen Fehler würde ich aber diesmal gerne vermeiden ;-)

Also Dein Problem besteht m.E. ganz einfach darin, dass Du einen (sehr?) komplexen realen Sachverhalt abbilden musst und dafuer keine "einfache" Loesung siehst (weil es sie nicht gibt).
1.) Die Todsuende solltest Du nicht begehen, denn dann machst Du definitiv etwas, was sich nicht mit dem Konzeot der relationalen Datenhaltung vertraegt.
2.) Eine grooossse Tabelle waere schon wesentlich besser. Eine dulle und einfache Loesung, die keinen Schoenheitspreis verdient, aber manchmal (erfahrungsgemaess) die Richtige ist.
3.) "Profikorrekt" scheint mir aber den komplexen Sachverhalt auch etwas komplexer abzubilden, d.h. mehrere Tabellen. (Allerdings nur dann, wenn die "Gemeinsamkeiten" der Objekte nicht zu gross sind.)

Ausserdem koenntest Du bei Deiner Entscheidungsfindung Deine persoenliche Situation beruecksichtigen, d.h.

  • kannst Du Deine Machtposition mit einer falschen Implementierung ausbauen? (Oder bringt es Geld?)
  • wird die Loesung wartungsfrei werden, weil ein anderer sich darum kuemmern muss?
  • laesst sich da i.p. Wiederverwertbarkeit was machen? (Also dann bitte "profikorrekt" designen.)

Interessante Problematik.

Gruss,
Lude