Datenhaltungs-Problem

[Andreas Korthaus]

Hallo!

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 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. 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.
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
...

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?

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?

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 ;-)

Viele Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

[...] (entschuldige, wenn ich alles wegwische, aber ich weiss nicht, auf was ich mich
explizit beziehen soll)

Allgemein habe ich folgende Bemerkungen:
Du hast mehrere Objekte, welche gemeinsame Daten haben, jedoch dann noch spezielle
Angaben die vom Typ des Objektes abhängig sind.
Aus der Datenbankmodellierung sind zwei Möglichkeiten vorhanden, dies gut zu lösen:

a) die horizontale Partitionierung
b) die vertikale Partitionierung

Du musst erkennen, dass "Einfamilienhäuser", "Wohnungen" und "Ferienhäuser" Subtypen von
"Immobilien" sind; sie stehen also in einer ISA (is-a => "ist ein") Beziehung.

Immobilien
                  |
                 ISA
                / | \                /  |  \               /   |   \              /    |    \    Ferienhaus  Wohnung  Einfamilienhaus

Nun, dies lässt sich (wie oben angedeutet) auf zwei Arten in ein Relationenschema um-
wandeln:

Tbl_Immobilie

immobilien_id
preis
flaeche_des_grundstuecks
typ : ENUM('wohnung','ferienhaus','einfamilienhaus')    // evtl. (obwohl redundant bei
                                                        // disjunkter Partitionierung
                                                        // => jede imm_id einem Typ zug.)

Tbl_Wohnung

immobilien_id
kauf_preis

Tbl_Ferienhaus

immobilien_id
miet_preis

Tbl_EinfamHaus

immobilien_id
kauf_preis
anzahl_zimmer

oder die andere Möglichkeit: Für jedes Objekt eine Relation, welche alle möglichen
Attribute/Spalten enthält (was du vorschlägst).

Das ist zumindest das, was ich dir aus der Modellierung beitragen kann, was du dann
verwendest und der kleinste Aufwand darstellt, muss ich dir überlassen. Ich hoffe das
hilft dir etwas.

Viele Grüsse

Philipp

[Andreas Korthaus]

Hallo!

Du musst erkennen, dass "Einfamilienhäuser", "Wohnungen" und "Ferienhäuser" Subtypen von
"Immobilien" sind; sie stehen also in einer ISA (is-a => "ist ein") Beziehung.

Ja, wenn ich es so betrachte, hast DU eigentlich Recht. Das problem war, das die Verschiedenen Regionen firmenintern anders behandelt wurden, und so EIn Ferinhaus in Land 1 eine minimal andere Daten-Struktur aufweist, als in Land 2, udn es gibt tatsächlich Unterschiede. Es geht um die Länder Deutschland(regional, keine Ferienhäuser), Holland(nur Ferienhäuser) und Spanien(nur Ferienhäuser). Das Problem ist, in Spanien gibt es andere Arten von Ferienhäusern, ("Villa", "Finca"...), außerdem haben die Immobilien teilweise andere Attribute, so kommt es z.B. in Spanien öfter vor das ein Haus ein Schwimmbad hat, in Holland dagagan nie. Außerdem ist das noch bei der Eingabe ein problem, z.B. sie Ferienregion, die ist ebenfalls Länderspezifisch, das heißt das müßte ich auch extern in einer oder mehreren Tabellen speichern. Was nach Relationalitäts-GEsichtspunkten auch vernünftig ist, nur bringt das wieder eine gute Vermischung der Daten, wenn ich alle Regionen in einer Tabelle speichere.

oder die andere Möglichkeit: Für jedes Objekt eine Relation, welche alle möglichen
Attribute/Spalten enthält (was du vorschlägst).

Das ist mit im Augenblick die sympathischere Variante, da unabghängiger. Wenn ich(oder jemand anders) die Daten aus der Datenbank extrahieren will, wofür auch immer, geht das so mit einer Tabelle recht einfach, mit x Untertabellen die nicht untereinander Kompatibel sind schon schwieriger. Mit der ersten Variante bräuchte ich dann nicht eine Tabelle für Ferienhaus, sondern eine pro Typ pro Land. Auf der anderen Seite kommt es drauf an das die Anwendung an sich vernünftig funktioniert und erweiterbar ist. Denn mit der "Tabellen" Varinante muß ich ja auch die Zuweisung der Felder speichern,udn eine alggemeine Export-Funktion die so eine "all-in-one" Tabelle generiert ist ja auch schnell geschrieben, somit wäre das Problem auf die Aktuelle Anwendung, deren Handling, Erweiterbarkeit und Performance reduziert.

Das ist zumindest das, was ich dir aus der Modellierung beitragen kann, was du dann
verwendest und der kleinste Aufwand darstellt, muss ich dir überlassen. Ich hoffe das
hilft dir etwas.

Danke das hilft mir, und veranschaulicht das Problem sehr schön.

Mich interessieren vor allem auch Eure Meinungen, wie Ihr das machen würdet, bzw. welche Risiken die beiden Wege bergen.

Vielen Dank und viele Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

Du musst erkennen, dass "Einfamilienhäuser", "Wohnungen" und "Ferienhäuser" Subtypen von
"Immobilien" sind; sie stehen also in einer ISA (is-a => "ist ein") Beziehung.
Ja, wenn ich es so betrachte, hast DU eigentlich Recht. Das problem war, das die Verschiedenen Regionen firmenintern anders behandelt wurden, und so EIn Ferinhaus in Land 1 eine minimal andere Daten-Struktur aufweist, als in Land 2, udn es gibt tatsächlich Unterschiede. Es geht um die Länder Deutschland(regional, keine Ferienhäuser), Holland(nur Ferienhäuser) und Spanien(nur Ferienhäuser). Das Problem ist, in Spanien gibt es andere Arten von Ferienhäusern, ("Villa", "Finca"...), außerdem haben die Immobilien teilweise andere Attribute, so kommt es z.B. in Spanien öfter vor das ein Haus ein Schwimmbad hat, in Holland dagagan nie. Außerdem ist das noch bei der Eingabe ein problem, z.B. sie Ferienregion, die ist ebenfalls Länderspezifisch, das heißt das müßte ich auch extern in einer oder mehreren Tabellen speichern. Was nach Relationalitäts-GEsichtspunkten auch vernünftig ist, nur bringt das wieder eine gute Vermischung der Daten, wenn ich alle Regionen in einer Tabelle speichere.

Wenn das _SO_ kompliziert und verschachtelt ist, dann würde ich eine Zwischenlösung
vorschlagen. Die Haupttypen getrennt, jedoch kleinere Unterschiede in eine
"Datentyp-Tabelle" auslagern; denn die explizite Aufschlüsselung in einzelne Relationen
wäre zu komplex und würde zuviele Relationen entstehen lassen (was auch nicht Sinn der
Modellierung sein kann).

oder die andere Möglichkeit: Für jedes Objekt eine Relation, welche alle möglichen
Attribute/Spalten enthält (was du vorschlägst).

Das ist mit im Augenblick die sympathischere Variante, da unabghängiger. Wenn ich(oder jemand anders) die Daten aus der Datenbank extrahieren will, wofür auch immer, geht das so mit einer Tabelle recht einfach, mit x Untertabellen die nicht untereinander Kompatibel sind schon schwieriger.

Jein. Du kriegst ja alle Daten mit einem simplen NATURAL JOIN der Tabellen. Und
unabhängiger möchte ich bezweifeln; was wenn ein Attribut dazukommt? - Speicher weg
und zwar für _alle_ Immobilientypen und -arten, auch wenn das Attribut für andere gar
nicht relevant ist.

Mit der ersten Variante bräuchte ich dann nicht eine Tabelle für Ferienhaus, sondern eine pro Typ pro Land.

Hm. Ja, was du nun in eine ISA-Beziehung steckst und somit syntaktisch Trennst, kannst
du entscheiden; das mit den Häusertypen war eine Möglichkeit, da ich dort den meisten
Unterschied vermutete; wenn jedoch die Unterschiede der Länder grösser sind, macht dort
eine Aufsplittung der Schematas mehr Sinn. Die Aufsplittung hat nur einen Zweck:
Redundanz zu vermeiden und macht folglich dort am meisten Sinn, wo die Daten
unterschiedlicher sind.

Das ist zumindest das, was ich dir aus der Modellierung beitragen kann, was du dann
verwendest und der kleinste Aufwand darstellt, muss ich dir überlassen. Ich hoffe das
hilft dir etwas.
Danke das hilft mir, und veranschaulicht das Problem sehr schön.

Mich interessieren vor allem auch Eure Meinungen, wie Ihr das machen würdet, bzw. welche Risiken die beiden Wege bergen.

Meine Meinung hab ich kundgetan. Probleme sehe ich dabei, dass Datenbanken für die
Speicherung statischer Informationen geeignet sind, deine Anwendung jedoch dynamische
Informationen verwaltet, welche besser in einer XML-Datei aufgehoben wären.

Viele Grüsse

Philipp

[Andreas Korthaus]

Hallo Philipp!

Wenn das _SO_ kompliziert und verschachtelt ist, dann würde ich eine Zwischenlösung
vorschlagen. Die Haupttypen getrennt, jedoch kleinere Unterschiede in eine
"Datentyp-Tabelle" auslagern; denn die explizite Aufschlüsselung in einzelne Relationen
wäre zu komplex und würde zuviele Relationen entstehen lassen (was auch nicht Sinn der
Modellierung sein kann).

Meinst Du nicht lieber bei den Unterschieden _alle_ mögliche Spalten in die Tabelle Tbl_Ferienhaus mit einbauen, das werde nicht mehr als 5 Spalten sein. Der Speicherplatz macht kein Problem, ist zumindest vernachlässigbar, aber so eien Datentyp-Tabelle (meinst Du damit meinen 1. Vorschlag vom Anfang ode was anderes?), wäre doch erheblich unhandlicher und langsamer, oder?

Mich interessieren vor allem auch Eure Meinungen, wie Ihr das machen würdet, bzw. welche Risiken die beiden Wege bergen.

Meine Meinung hab ich kundgetan. Probleme sehe ich dabei, dass Datenbanken für die
Speicherung statischer Informationen geeignet sind, deine Anwendung jedoch dynamische
Informationen verwaltet, welche besser in einer XML-Datei aufgehoben wären.

Oh? Auf die Variante war ich ja nohc gar nicht gekommen! Aber - was meinst Du mit statisch oder dynamisch? Was ist an meinen Daten dynamisch? Das sie oft geändert werden? Wa shat das mit der Datenhaltung zu tun? IMHO ist gerade eine Datenban für sich oft ändernde Daten besser. Wobei, die Daten ändern sich nicht oft!

Aber die Idee finde ich gut, nur habe ich noch nie wirklich was mit XML gemacht, ich kenne nur ein  bisschen die Theorie. In diesem Fall, würde man alles in _einer_  XMl-Datei speichern? Ist das parsen denn dann nicht erheblich umständlicher?

Das heißt so eine Struktur wie:

<objekte>
 <objekt typ=ferienhaus>
   <id>123<id>
   <land>spanien</land>
   <beschreibung>asdlöasdlöälöd löasl köslakdöa köla</beschreibung>
 </objekt>
 <objekt typ=einfamilienhaus>
   <id>124<id>
   <land>deutschland</land>
   <beschreibung>asdlöasdlöälöd löasl köslakdöa köla</beschreibung>
 </objekt>
</objekte>

Sowas in der Art? Das heißt ich definiere so zu sagen eine DTD die festlegt was z.B. <objekt> enthalten darf. Nur ist das ja zu allgemein, das heißt ich verwende lieber nicht <objekt typ=ferienhaus>, sondern

<ferienhaus>, da kann ich dann genau definieren was das alles enhalten darf/soll.

Entsprechend dieser DTD generiere ich dann in html Eingabe-Formulare, halt das entsprechend die richtige Daten eingefügt werden. Meinst Du das so in etwa?

Aber wie soll ich die verschiedenen Datenstrzkturen unterschieden nach Land und Miete/Kauf abbilden?

Was bietet das denn jetzt für Vorteile gegenüber einer Datenbank?

Ist ein sehr interessantes Thema, danke für den Tipp!

Viele Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

Wenn das _SO_ kompliziert und verschachtelt ist, dann würde ich eine Zwischenlösung
vorschlagen. Die Haupttypen getrennt, jedoch kleinere Unterschiede in eine
"Datentyp-Tabelle" auslagern; denn die explizite Aufschlüsselung in einzelne Relationen
wäre zu komplex und würde zuviele Relationen entstehen lassen (was auch nicht Sinn der
Modellierung sein kann).
Meinst Du nicht lieber bei den Unterschieden _alle_ mögliche Spalten in die Tabelle Tbl_Ferienhaus mit einbauen, das werde nicht mehr als 5 Spalten sein. Der Speicherplatz macht kein Problem, ist zumindest vernachlässigbar, aber so eien Datentyp-Tabelle (meinst Du damit meinen 1. Vorschlag vom Anfang ode was anderes?), wäre doch erheblich unhandlicher und langsamer, oder?

Ja, ich meinte den 1. Vorschlag (den von dir; mit Feld_ID etc.). OK, wenn der
Speicherplatz kein Problem ist, ist sicherlich die Lösung mit einer Tabelle/Typ besser,
da brauchst du keine JOIN's (JOIN's sind ja bekanntlich langsam); zudem vereinfacht das
das manuelle Bearbeiten der Daten (eg. über phpMyAdmin)...

Mich interessieren vor allem auch Eure Meinungen, wie Ihr das machen würdet, bzw. welche Risiken die beiden Wege bergen.

Meine Meinung hab ich kundgetan. Probleme sehe ich dabei, dass Datenbanken für die
Speicherung statischer Informationen geeignet sind, deine Anwendung jedoch dynamische
Informationen verwaltet, welche besser in einer XML-Datei aufgehoben wären.

Oh? Auf die Variante war ich ja nohc gar nicht gekommen!

*freu* :-)

Aber - was meinst Du mit statisch oder dynamisch? Was ist an meinen Daten dynamisch?

Statische Daten bleiben _immer_ gleich; du beschreibst sehr, sehr viele Sonderfälle, die
von Ländern, Typen etc. etc. abhängen; es ist also wahrscheinlich (und wenn die
Wahrscheinlichkeit grösser 0 ist, ist es eben nicht mehr statisch), dass die
Datenstruktur ändert => Wenn eine Datenstruktur Änderungen unterliegt oder über
parametrisierung starken Änderungen unterliegt, ist sie dynamisch.
? - Ich komme in Argumentationsnot :-)   Naja, vielleicht ist der Sinn dennoch halbwegs
hinübergekommen ;)

Das sie oft geändert werden? Wa shat das mit der Datenhaltung zu tun? IMHO ist gerade eine Datenban für sich oft ändernde Daten besser. Wobei, die Daten ändern sich nicht oft!

Nein, ich sprach von dem _Schema_, nicht von den Schemaausprägungen (Records). Es geht
nicht um Daten, sondern deren Struktur und diese ist bei dir eben sehr verzweigt und
reich an Struktur, die von gewissen Parametern (Ländern, Typen, ...) abhängt.

Aber die Idee finde ich gut, nur habe ich noch nie wirklich was mit XML gemacht, ich kenne nur ein  bisschen die Theorie. In diesem Fall, würde man alles in _einer_  XMl-Datei speichern? Ist das parsen denn dann nicht erheblich umständlicher?

Nun ja, die Entscheidung DB <-> XML ist alles andere als einfach. Ich wollte nur
anmerken, dass die Anforderungen an deinen Datentypen eher zu XML "passt", als zu einer
Datenbank. Wenn du noch keine grösseren Projekte mit XML umgesetzt hast, würde ich dir
doch den Weg über die Datenbank empfehlen (neben bei kannst du ja mal ein grösseres
Projekt mit XML umsetzen, aber mach das dir zu liebe nicht unter Zeitdruck).
Der Zeitaufwand des Parsens steigt natürlich proportional zur Dateigrösse; wobei du
die Daten auf mehrer Files aufschlüsseln könntest (naja, dafür musst du dann mehrere
Files parsen, aber eben nicht alle).

<objekte>

[...]

</objekte>

mit typ="ferienhause" ;)
wäre eine Möglichkeit, wie man dies repräsentieren könnte, ja. Aber in XML bist du
ja zeimlich frei...

Sowas in der Art? Das heißt ich definiere so zu sagen eine DTD die festlegt was z.B. <objekt> enthalten darf. Nur ist das ja zu allgemein, das heißt ich verwende lieber nicht <objekt typ=ferienhaus>, sondern

<ferienhaus>, da kann ich dann genau definieren was das alles enhalten darf/soll.

Naja, lass die DTD doch einfach weg (*ja-ich-warte-auf-Schläge*), macht nur
Kopfschmerzen :-)  Oder möchtest du die XML-Datei jedesmal validieren? - Da du alleine
auf die Daten zugreifst, kannst du das natürlich auch durch dein Programm sicherstellen.

Entsprechend dieser DTD generiere ich dann in html Eingabe-Formulare, halt das entsprechend die richtige Daten eingefügt werden. Meinst Du das so in etwa?

Naja, du denkst glaub ich etwas zu weit. Stell dir einfach vor, XML sei nix anderes
als die MySQL-DB... Du erstellst ein GUI, liest die Daten ein und gibtst diese aus;
nur heisst die Abfragesprache nicht SQL, sondern XML.DOM oder XML.SAX oder sonst was...

Aber wie soll ich die verschiedenen Datenstrzkturen unterschieden nach Land und Miete/Kauf abbilden?

Hm. Ich habe die Beziehung dieser Einflussfaktoren noch nicht wirklich begriffen, kannst
du diese nochmals kurz beschreiben? - Was ändert wann? - Von was ist was abhängig?

Was bietet das denn jetzt für Vorteile gegenüber einer Datenbank?

a) du bist nicht auf Schema-Attribute angewiesen
b) du kannst nach belieben neue Attribute hinzufügen oder löschen, ohne, dass du
   ein Datenbankschema ändern musst (OK, wenn du gegen eine DTD validiest, hast du
   [fast] wieder das selbe "Problem")
c) bei einem grossen System wird die XML-Variante wohl langsamer sein.
d) du musst nicht kurriose Relationsgymnastik(tm) betreiben, um die Daten logisch zu
   strukturieren...

Viele Grüsse

Philipp

[Andreas Korthaus]

Hallo Philipp!

Statische Daten bleiben _immer_ gleich; du beschreibst sehr, sehr viele Sonderfälle, die
von Ländern, Typen etc. etc. abhängen; es ist also wahrscheinlich (und wenn die
Wahrscheinlichkeit grösser 0 ist, ist es eben nicht mehr statisch), dass die
Datenstruktur ändert

Eben nicht. Entweder ein Objekt ist ein Ferienhaus zur Miete in Spanien, oder ein Einfamilienhaus zum Kauf in Deutschland. Da wird nichts geändert. Es ist eine ganz feste(statische) Struktur. Ich habe von Ändern nur gesprochen, da evtl. was an der Struktur verbessert werden könnte, das hat aber nur mit der Entwicklung zu tun.

Nun ja, die Entscheidung DB <-> XML ist alles andere als einfach. Ich wollte nur
anmerken, dass die Anforderungen an deinen Datentypen eher zu XML "passt", als zu einer
Datenbank. Wenn du noch keine grösseren Projekte mit XML umgesetzt hast, würde ich dir
doch den Weg über die Datenbank empfehlen (neben bei kannst du ja mal ein grösseres
Projekt mit XML umsetzen, aber mach das dir zu liebe nicht unter Zeitdruck).
Der Zeitaufwand des Parsens steigt natürlich proportional zur Dateigrösse; wobei du
die Daten auf mehrer Files aufschlüsseln könntest (naja, dafür musst du dann mehrere
Files parsen, aber eben nicht alle).

Die Perfromance ist wie gesagt nebensächlich da ich wie gesagt weniger als 1000 Objekte haben werde und das werden auch nicht viel mehr. Das problem ist eher die semantische Seite.

<objekte>
[...]
</objekte>

mit typ="ferienhause" ;)

Ja, stimmt ;-) Ok, was denn noch als Attribut, ID auf alle Fälle, vielleicht noch Land und Miete/Kauf? Und der rest entsprechend den Attributen als Unterelemente? Mein Problem ist nur, wie/womit lege ich dies fest? Daher die DTD. Das man die nicht braucht ist klar, Und wenn man sio nicht braucht ist es nicht verwerflich darauf zu verzichten, nur bietet die DTD eine Möglichkeit die Struktur darzustellen, ich wüßte nicht wie ich das sonst machen könnte.

Entsprechend dieser DTD generiere ich dann in html Eingabe-Formulare, halt das entsprechend die richtige Daten eingefügt werden. Meinst Du das so in etwa?

Naja, du denkst glaub ich etwas zu weit. Stell dir einfach vor, XML sei nix anderes
als die MySQL-DB... Du erstellst ein GUI, liest die Daten ein und gibtst diese aus;
nur heisst die Abfragesprache nicht SQL, sondern XML.DOM oder XML.SAX oder sonst was...

Ok. Nur geht das dann nicht mehr mit PHP, die domxml Funktionen sind noch nicht stabil genug. Aber das soll mir erstmal egal sein, es gibt ja noch PERL...

Hm. Ich habe die Beziehung dieser Einflussfaktoren noch nicht wirklich begriffen, kannst
du diese nochmals kurz beschreiben? - Was ändert wann? - Von was ist was abhängig?

OK.

Es sind alles zum Verkauf oder zur Vermietung stehende Immobilien-Objekte. Die Objekte sollen in der Anwendung gespeichert werden, sie sollen in dem Format bearbeitbar sein, d.h. man soll über ein Web-Interface ein neues Objekt anlegen können, ein bestehendes Objekt ändern können, und Objekte löschen können. Darüber hinaus sollen die Objekte auf der Homepage dargestellt werden, vielleicht hilft Dir das ja:

Auf der Homepage soll es für jede Region eine eigene Unterseite geben, halt für Deutschland, Spanien und Holland, denn es sucht wohl kaum jemand ein Objekt gleichzeitig in den 3 Ländern.

Auf der Unterseite soll kann man dann nach Region(z.B. Ferienregion in Spanien) oder Objelttyp(z.B. Villa, Ferienwohnung) ausswählen können, und auch ob Miet-Objekt oder Kauf-Objekt. Dann erhält man eine Übrsicht ale Objekte, die der Auswahl genügen, udn kann sich dann jedes einzelnde detailiert ansehen. So ist es jetzt und so soll es auch bleiben. Das ist jetzt die Präsentation, was ja mit der Datenhaltung nicht unbedingt so viel zu tun hat, aber vielleicht hilft es fürs Verständnis.

Dann mal zur Datenstruktur(_etwas_ geändert, denn das was ich vorhatte ist wirklich zu komplex!):

• Ein Objekt kann entweder ein Kaufobjekt oder ein Mietobjekt sein.

• Ein Objekt hat ein Attribut Land

• Ein Objekt hat ein Attribut Typ, also z.B. Ferienhaus, Einfamilienhaus, welche Typen bei der Auswahl zur Verfügung stehen hängt vom jeweiligen Attribut Land ab. Es kann also nicht jedes Objekt jeden Typ haben, das ist abhängig von dem jeweiligen Attribut Land.

• Die Objekte haben nur wenige Eigenschaften gemeinsam, eigentlich nur Kaufpreis/Miete + Nebenkosten, Adresse, Verkäufer/Vermieter, Status(verkauft, neu...)

• Alle anderen Eigenschaften sind abhängig vom Attribut Objekttyp, nicht vom Attribut Land(gestrichen, da zu komplex). Das heißt
    -> ein Objekt mit dem Attribut Typ=Ferienhaus hat Eigenschaften wie Grundstückgröße, Wohnfläche, Garagen, Schwimmbad, unterkellert...
    -> ein Objekt mit dem Attribut Typ=Wohnung hat die Eigenschaften Wohnfläche, Etage, Garage, Kellerraum...

Das ist jetzt unabhängig davon in welchem Land und ob Miete oder nicht.

Es sind nur die paar wenigen Dinge wie statt Kaufpreis dann Miete und Nebenkosten, und evtl noch 1 oder 2 Eigentums-spezifische Eigenschaften, die probleme bereiten. Die Frage ist jetzt, lohnt es sich diese paar Spalten in einer/mehrere Extra-Tabellen zu packen, oder ob ich nicht mit einer etwas vergrößerten Objekttabelle, also

Tbl_Immobilien:
 - Objekt_ID
 - Typ_ID
 - Eigentumsverhältnis(selten dummer Name aber ich weiß keinen besseren, ist für Miete/Kauf)
 - Kaufpreis (Nur wenn vorherige Spalte auf KAUF steht ausgefüllt)
 - Miete (Nur wenn vorherige Spalte auf MIETE steht ausgefüllt)
 - Nebenkosten (Nur wenn vorherige Spalte auf MIETE steht ausgefüllt)
 - Adresse...
 - Land
 - Verkäufer_ID
 - Status(verkauft, neu...)
 - erstellt am

Und dann für jeden Typen eine Tabelle:

Tbl_Ferienhaeuser
 - Objekt_ID
 - Grunstücksfläche
 - Wohnfläche
 - Garage
...

Dann müßte ich halt nur noch über die entsprechende Tabelle joinen und fertig. Vielleicht noch eine Tabelle den Objekttypen:

Tbl_Objekt_Typen
 - Typ_ID
 - Bezeichnung

Noch länder

Tbl_Laender
 - Land_ID
 - Landname

Und noch die Verknüpfung, damit ich bei der Eingabe weiß welches Land hat welchen Typen :

Tbl_Land_Typ
 - Land_ID
 - Typ_ID

Wobei ich Probleme habe eine Tabelle mit 3 Datensätzen(Länder), naja. Jedenfalls ist das so gut erweiterbar, oder? Was hälst Du von diesem Entwurf? Oder soll ich das mit der Miete doch rausziehen?

Und das ist es eigentlich. Es tut mir Leid das ich dich so verwirrt habe, aber wo ich gerade so am schreiben war habe ich mir gedacht, solche Abenteuerlichen Sachen in der Datenbank, oder in XML abzubilden, da steht der Aufwand nicht mehr Im Verhältnis zum Ertrag.

Um trotzem nochmal auf XML zurückzukommen, ich könnte obige Struktur ja durchaus in einer DTD abbilden, oder? Somit hätte ich was, woran ich mich orientieren kann, naja.

Was bietet das denn jetzt für Vorteile gegenüber einer Datenbank?
a) du bist nicht auf Schema-Attribute angewiesen

Wenn ich kei festes Schema habe, wie soll ich dann automatisiert auf einer Homepage auf die Daten zugreifen?

b) du kannst nach belieben neue Attribute hinzufügen oder löschen, ohne, dass du
   ein Datenbankschema ändern musst (OK, wenn du gegen eine DTD validiest, hast du
   [fast] wieder das selbe "Problem")

das brauche ich ja nicht. Wenn Du nochmal die Struktur oben anschaust, wäre es dann nicht doch besser auf eine relationale Datenbank zu setzen? Es wäre sicher eine Möglichkeit mal XML zu lernen, nur kann ich den Aufwand nicht wirklich abschätzen.

c) bei einem grossen System wird die XML-Variante wohl langsamer sein.

bei <1000 Objekten wohl kein Thema, oder?

d) du musst nicht kurriose Relationsgymnastik(tm) betreiben, um die Daten logisch zu
   strukturieren...

Dafür braucht es um so mehr Gymnastik um auf die Daten zuzugrifen und diese zu verändern und darzustellen, dafür ist die Abstraktions-Ebene von SQL schon ganz praktisch, oder?

Viele Grüße und Danke nochmal!
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

Statische Daten bleiben _immer_ gleich; du beschreibst sehr, sehr viele Sonderfälle, die
von Ländern, Typen etc. etc. abhängen; es ist also wahrscheinlich (und wenn die
Wahrscheinlichkeit grösser 0 ist, ist es eben nicht mehr statisch), dass die
Datenstruktur ändert
Eben nicht. Entweder ein Objekt ist ein Ferienhaus zur Miete in Spanien, oder ein Einfamilienhaus zum Kauf in Deutschland. Da wird nichts geändert. Es ist eine ganz feste(statische) Struktur. Ich habe von Ändern nur gesprochen, da evtl. was an der Struktur verbessert werden könnte, das hat aber nur mit der Entwicklung zu tun.

OK, hast recht, deine Daten sind statisch. => DB macht Sinn (... was XML zwar nicht
ausschliesst).

Ja, stimmt ;-) Ok, was denn noch als Attribut, ID auf alle Fälle, vielleicht noch Land und Miete/Kauf?

In XML bist du hier frei, wenn du jedoch auf XML.DOM und XML.SAX schaust, wirst du sehen,
dass du schneller auf die Attribute zugreifen kannst. Es empfiehlt sich also, die
wichtigsten und am häufigst benutzten Daten als Attribute zu speichern. In deinem
Fall würde ich also ein "Flag" ob Miete oder Kauf + Land noch dazunehmen.

Und der rest entsprechend den Attributen als Unterelemente?

jep.

Mein Problem ist nur, wie/womit lege ich dies fest? Daher die DTD. Das man die nicht braucht ist klar, Und wenn man sio nicht braucht ist es nicht verwerflich darauf zu verzichten, nur bietet die DTD eine Möglichkeit die Struktur darzustellen, ich wüßte nicht wie ich das sonst machen könnte.

ER-Diagramm :-)
Du kannst dies auf mehrere Arten zun, über ER-Diagramme, im Gedächtnis, auf Papier,
mit einem eigenen Diagramm, über DTD oder gar über M$'s ORM (ObjectRoleModell).
Die Darstellung spielt ja keine Rolle, du musst dir deines Schemas nur selber treu
und bewusst sein. Du kannst natürlich auch einfach ein Beispiel schreiben(XML), sodass du
die Struktur immer gleich beispielhaft auf einen Blick vor dir hast.

Entsprechend dieser DTD generiere ich dann in html Eingabe-Formulare, halt das entsprechend die richtige Daten eingefügt werden. Meinst Du das so in etwa?

Naja, du denkst glaub ich etwas zu weit. Stell dir einfach vor, XML sei nix anderes
als die MySQL-DB... Du erstellst ein GUI, liest die Daten ein und gibtst diese aus;
nur heisst die Abfragesprache nicht SQL, sondern XML.DOM oder XML.SAX oder sonst was...
Ok. Nur geht das dann nicht mehr mit PHP, die domxml Funktionen sind noch nicht stabil genug. Aber das soll mir erstmal egal sein, es gibt ja noch PERL...

Perl!!! Perl!!! :-)

[... Beschreibung der Daten...]

- Objekt -> (Kauf- | Mietobjekt)
 - Objekt hat Typ (Ferienhaus | Einfamilienhaus)
 - Objekt hat Land
 - Objekt hat (Kaufpreis/Miete+Nebenk. & Adresse & Verkäufer/Mieter & Status &
   Wohnfläche)
   ^^^^^^^^^^^ => Da in Ferienhaus+Wohnung in Objekt modelliert.
 - Ferienhaus hat (Grundstückgrösse & Garagen & Schwimmbad & ...)
 - Wohnung hat (Etage & Garage & Kellerraum)

*musste ich kurz zusammenfassen*

Bemerkungen und Anregungen:
 - Die Abhängigkeit vom Land ist IMHO nebensächlich und muss nicht modelliert werden
   (ggf. sogar vom Programm übernommen)
 - Wie du es modelliert hast finde ich OK (Tbl_Objekte, Tbl_*typ*)
 - Das Problem ist: zwei ISA's, entweder Abhängig von Miete oder von Typ =>
   => die Möglichkeiten nehmen schnell zu => nur von Typ abhängig machen, halte ich für
      richtig.
 - Möglichkeiten für zwei ISA's Konstruktion:
   - Du könntest zwei Tabellen machen, wo die objekt_id (immobilien_id) primary key ist,
     und jeweils Mietattribute oder Kaufattribute stehen (sog. schwache Entitäten).

Beispiel: (in etwa deckungsgleich mit deinem)

Tbl_Immobilien : (immobilien_id, typ_id, ...)  // warum objekt_id? - immobilien_id nicht
                                               // logischer?
Tbl_Ferienhaeser : (immobilien_id, Grundstücksfläche, ...)
Tbl_Wohnung : (Garagen, Etage, Kellerraum, ...)
Tbl_Kauf : (immobilien_id, preis, gekauft_am, ...)
Tbl_Miete : (immobilien_id, mt_preis, letzte_zahlung, ...)

das wäre eine Möglichkeit, dass du dennoch auf Kauf und Miete aufsplitten könntest, ohne
für Ferienhaeser und Wohnung explizit noch jeweils zwei weitere Tabellen anlegen
müsstest. Wie gesagt, kein Problem, wenn du alles in zwei Tabellen modellierst (also
Kauf und Miete weglässt), wollt nur das andere auch noch nennen.

Es sind nur die paar wenigen Dinge wie statt Kaufpreis dann Miete und Nebenkosten, und evtl noch 1 oder 2 Eigentums-spezifische Eigenschaften, die probleme bereiten. Die Frage ist jetzt, lohnt es sich diese paar Spalten in einer/mehrere Extra-Tabellen zu packen, oder ob ich nicht mit einer etwas vergrößerten Objekttabelle, also

Ich werde schwach: Nein, es lohnt sich nicht. Wenn der Speicher keine Rolle spielt, dann
geht das natürlich auch in einer grossen Tabelle. Das bringt dir noch einige Vorteile:
schneller zum Umsetzen; einfachere Abfragen; performantere Abfragen; und, leider, ein
wenig Redundanz.

Tbl_Objekt_Typen
 - Typ_ID
 - Bezeichnung
Noch länder
Tbl_Laender
 - Land_ID
 - Landname
Und noch die Verknüpfung, damit ich bei der Eingabe weiß welches Land hat welchen Typen :
Tbl_Land_Typ
 - Land_ID
 - Typ_ID

Ich glaube, dass du die Land_Typ - Tabelle sogar auslassen kannst. Das kompliziert die
Abfragen und bringt nicht sehr viel. Du kannst die Steuerung dessen in das Programm
integrieren.

Wobei ich Probleme habe eine Tabelle mit 3 Datensätzen(Länder), naja. Jedenfalls ist das so gut erweiterbar, oder? Was hälst Du von diesem Entwurf? Oder soll ich das mit der Miete doch rausziehen?

s. oben. Nein, würde ich in Anbetracht des Aufwand/Nutzen nicht.

Um trotzem nochmal auf XML zurückzukommen, ich könnte obige Struktur ja durchaus in einer DTD abbilden, oder? Somit hätte ich was, woran ich mich orientieren kann, naja.

wie gesagt, die DTD ist _eine_ von vielen Möglichkeiten.

Was bietet das denn jetzt für Vorteile gegenüber einer Datenbank?
a) du bist nicht auf Schema-Attribute angewiesen
Wenn ich kei festes Schema habe, wie soll ich dann automatisiert auf einer Homepage auf die Daten zugreifen?

Sorry für die Verwirrung: Du hast schon ein festes Schema, aber ob die Attribute
gespeichert werden oder nicht, kannst _du_ bestimmen, nicht die Datenbank. In der DB
kannst du nicht "willkührlich" ein Attribut dazufügen, da müsstest du erst das Datenbank-
Schema erweitern. Bei XML bist du da frei. Wenn du z. B. ein Mietobjekt hast, musst du
nicht notgedrungen auch alle Informationen zu dem Kauf speichern (in der DB Variante,
müssen die Attribute gespeichert werden, da du dies so definiert hast).
Was du also für die Homepage brauchst, ist die Information welcher Art das Objekt ist,
dann brauchst du eine Liste mit den "validen Attributen für dieses Objekt" und kannst
diese Auslesen (eg. Typ Ferienhaus => 'Grundstück', 'Wohnfläche').

b) du kannst nach belieben neue Attribute hinzufügen oder löschen, ohne, dass du
   ein Datenbankschema ändern musst (OK, wenn du gegen eine DTD validiest, hast du
   [fast] wieder das selbe "Problem")
das brauche ich ja nicht. Wenn Du nochmal die Struktur oben anschaust, wäre es dann nicht doch besser auf eine relationale Datenbank zu setzen? Es wäre sicher eine Möglichkeit mal XML zu lernen, nur kann ich den Aufwand nicht wirklich abschätzen.

deshalb habe ich dir die Lösung über DB empfohlen. Wenn du mal Zeit hast und an keinen
Zeitplan gebunden bist, kannst du das System in XML portieren; aber ich würde nicht auf
den Erfolg pokern (ob die Lösung über XML ohne grössere Erfahrungen zum Erfolg kommt).
Und ja, du hast mich davon überzeugt, dass dein Schema statischer Natur ist, demnach,
bietet sich eine DB natürlich an.

c) bei einem grossen System wird die XML-Variante wohl langsamer sein.
bei <1000 Objekten wohl kein Thema, oder?

Nun, das Problem liegt ganz wo anders. Bei XML bist du gezwungen _alle_ Daten einzulesen
und belastest den RAM-Speicher stark. Bei DB's ist es lediglich eine Selektion eines
einzigen Records. Was daraus folgt: Die DB braucht nur einen Index und wird schnell
einen Datensatz selektieren können, der XML-Parser muss die gesamte Datei einlesen.
Bei <1000 Objekten dürfte das noch nicht grossartig ins Gewicht fallen; bei grösseren
Datenmengen sehr wohl; was auch problematisch werden könnte, ist, wenn ein Datensatz
viel Speicher braucht (eg. 2000 Bytes / Objekt => 2MB Speicher [und jetzt kommt noch
die Perl-Repräsentation der Skalare und die DOM-Hierarchie, dann kommst du schnell auf
10MB] ).

d) du musst nicht kurriose Relationsgymnastik(tm) betreiben, um die Daten logisch zu
   strukturieren...
Dafür braucht es um so mehr Gymnastik um auf die Daten zuzugrifen und diese zu verändern und darzustellen, dafür ist die Abstraktions-Ebene von SQL schon ganz praktisch, oder?

Völlig richtig!

Viele Grüsse und HTH

Phil*finger-wund*ipp ;)

[Thomas J.S.]

Hallo Philipp,

Nun, das Problem liegt ganz wo anders. Bei XML bist du gezwungen _alle_ Daten einzulesen
und belastest den RAM-Speicher stark.

Wenn man den Zugriff auf das XML über DOM Realisiert stimmt das. Beim Zugriff über einen SAX-Parser stimmt das nicht mehr, da SAX event-basiert arbeitet.

Grüße
Thomas

[Philipp Hasenfratz]

Halihallo Thomas

Nun, das Problem liegt ganz wo anders. Bei XML bist du gezwungen _alle_ Daten einzulesen
und belastest den RAM-Speicher stark.

Wenn man den Zugriff auf das XML über DOM Realisiert stimmt das. Beim Zugriff über einen SAX-Parser stimmt das nicht mehr, da SAX event-basiert arbeitet.

Ich weiss, und dennoch wirst du bei XML nicht umher kommen die ganze Datei einzulesen,
wie der Inputstream verarbeitet wird, ist nicht relevant. Die Datenbank öffenet
den Index, braucht ca. 17 Zugriffe, um einen Datensatz aus 1'000'000 zu selektieren und
schon hat man ihn; wichtig ist hierbei (und davon spreche ich), dass nicht alle 1'000'000
Datensätze gelesen werden müssen (wie in XML, Eventbasiert oder nicht).
Gut, du hast recht in dem Sinne, dass man mit eventbasierten Parsern die Verarbeitung
abbrechen könnte, hätte man das Element gefunden, welches man benötigt; aber auch dann
musst du durchschnittlich die halbe Datei Parsen.

Viele Grüsse

Philipp

[Thomas J.S.]

Hallo Andreas,

Es sind alles zum Verkauf oder zur Vermietung stehende Immobilien-Objekte. Die Objekte sollen in der Anwendung gespeichert werden, sie sollen in dem Format bearbeitbar sein, d.h. man soll über ein Web-Interface ein neues Objekt anlegen können, ein bestehendes Objekt ändern können, und Objekte löschen können. Darüber hinaus sollen die Objekte auf der Homepage dargestellt werden, vielleicht hilft Dir das ja:

Wenn die software noch nicht 100% festgeschrieben wurde, könntest du dir einen XML-Server anschauen, in deinem Fall vielleicht den TeXtML-Server von http://www.ixiasoft.com.

Grüße
Thomas

[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

[Andreas Korthaus]

Hi Philipp!

noch 'n bissle mehr... ;)

Auf das wollte ich in meiner Antwort eben auch noch eingehen, hatte es aber glatt vergessen ;-)

Jetzt wirds noch komplizierter ;-)

Sehr gut!

Also aus Sicht der Datenbankmodellierung würde das dann so aussehen:

... alter Informatiker...
*ggg*

Muß aber zugeben diese Sichweite bringt tatsächlich etwas Klarheit in mein Wirrwar ;-)

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.

Hm, hab ich das jetzt richtig verstanden? Du würdest die Daten in jeweils 3 Tabellen aufteilen? Wäre es nicht schlauer, in der Tabelle Immobilien, den Typ(Ferinhaus), das Land(Spanien) und ob Miete/Kauf zu speichern, und dann direkt über die letzte Tabelle mit _allen_ Daten zu joinen? Das Autteilen von Daten in mehrere Tabellen finde ich nicht gut. ich hätte dann die Tabelle Tbl_Immobilien mit den oben beschriebenen Angaben, und die Tabelle Tbl_Ferienhaus_miete und Tbl_Ferienhaus_kauf, Bei einer SQL-Abfrage weiß ich ja vorher schon ganz genau was ich wilsen will, also Ferienhaus, Spanien, Miete, entsprechend kann ich direkt über beide Tabellen joinen. Wobei, wenn ich nochmal drüber nachdenke, die meisten Daten bei miete und verkauf sind ja gleich, nur ein paar sind verschieden. Hm. Lohnt es soch hier nichtmal 2-3 spezifische Spalten ij der Ursprungstabelle zu halten, oder vielleicht direkt in der Tabelle Tbl_Immobilien, denn diese Daten sind überall gleich, da brauche ich ja dann  nicht in jeder Untertabelle diese extra-Spalten, oder?

[...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.

hast Recht vergiss es!

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 ;)

jepp ;-)

(Gut das ich nachgefragt habe ;-))))

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.

Das ist ja nicht das Problem - wieviel Platz braucht NULL? Wenn ich damit Rechne das ich im Schnitt 70% der Spalten nicht brauche, dann wird es doch am Ende drauf hinaus laufen, dass ich vielleicht 20, vielleicht 30 % merh speicherplatz bracuhe - wenn überhaupt. Das ist bei meienr Anwendung vollkommen irrelevant, wenn es das Speicherplatz-Problem an sich ist. Es ist um den Faktor 1000 mehr Speicherplatz verfügbar, als zu Zeit genutzt wird. Und auch Performance ist kein wichtiger Faktor, da es sich um nichtmal 1000 Datensätze handelt. Es geht vor allem um Dinge wie Datenintigirität, Stabilität, Erweiterbarkeit, einfach zu handelnde Datenstruktur... und nicht zuletzt um eine gute, funktionale Datenstruktur.

Zur Zeit habe ich noch ein Problem damit für jede Objektart eine Extra-Tabelle zu erstellen, nicht weil ich Angst vor vielen Tabellen habe, sondern das es unüberschaubarer wird, ich habe ein anderes Projeklt mit knapp 100 Tabellen, alles schön Relational mit vielen sehr tiefen Joins, das ist manchmal ganz schön kompliziert!

Die Sache hier  ist, das sich alle Objekte bis zu einem Bestimmten Grad von den Attributen nicht unterschieden, und dann wird nach Typ unterschieden, und bei einem kleinen Teil der Attribute dann wieter nach Land, und bei noch ein paar Attributen nach Miete/Kauf.

Wenn ich dann mal alle Kombinationsmögichkeiten ausrechne:

3 Länder
8 Typen
2 (Miete/Kauf)

Brauche ich für die eigentlich ähnlich strukturierten Immobilien-Objekte knapp 50 Tabellen. Wenn ich jetzt mal an allen was ändern will, was eigentlich überall gleich ist, wird das schwer!

Vielen Dank und viele Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

noch 'n bissle mehr... ;)
Auf das wollte ich in meiner Antwort eben auch noch eingehen, hatte es aber glatt vergessen ;-)

Jetzt wirds noch komplizierter ;-)
Sehr gut!

Ich bin es nicht, der das Umsetzen muss :-)

Also aus Sicht der Datenbankmodellierung würde das dann so aussehen:
... alter Informatiker...
*ggg*

*rot-anlauf* hab doch erst vor kurzem meinen ersten Schein geschrieben ;-)

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.
Hm, hab ich das jetzt richtig verstanden? Du würdest die Daten in jeweils 3 Tabellen aufteilen? Wäre es nicht schlauer, in der Tabelle Immobilien, den Typ(Ferinhaus), das Land(Spanien) und ob Miete/Kauf zu speichern, und dann direkt über die letzte Tabelle mit _allen_ Daten zu joinen? Das Autteilen von Daten in mehrere Tabellen finde ich nicht gut. ich hätte dann die Tabelle Tbl_Immobilien mit den oben beschriebenen Angaben, und die Tabelle Tbl_Ferienhaus_miete und Tbl_Ferienhaus_kauf, Bei einer SQL-Abfrage weiß ich ja vorher schon ganz genau was ich wilsen will, also Ferienhaus, Spanien, Miete, entsprechend kann ich direkt über beide Tabellen joinen. Wobei, wenn ich nochmal drüber nachdenke, die meisten Daten bei miete und verkauf sind ja gleich, nur ein paar sind verschieden. Hm. Lohnt es soch hier nichtmal 2-3 spezifische Spalten ij der Ursprungstabelle zu halten, oder vielleicht direkt in der Tabelle Tbl_Immobilien, denn diese Daten sind überall gleich, da brauche ich ja dann  nicht in jeder Untertabelle diese extra-Spalten, oder?

Allgemeine Anmerkung: Ich habe die Anforderungen versucht zu modellieren, du versuchst
sie zu praktizieren. Der Unterschied ist: Die Modellierung konzentriert sich allein
auf die Daten, du denkst schon an deren Selektierung; beides hat Vor- und Nachteile.
Deine Lösung ist schneller Umzusetzen und ruft Redundanz hervor, die nicht weiter
schlimm sind (Speicher sei ja nicht wichtig). Die der Modellierung ist weitestgehend
redundanzfrei, jedoch nicht mehr so "Anfrageoptimiert".
Naja, soganz weiss ich nicht, wie du mich interpretiert hast :-)
Was ich (einfach ausgedrückt) sagen möchte ist folgendes:
Gleiche Daten gehören in die gleiche Tabelle. Daten, die speziell und ausschliesslich
einem "Untertyp" zugeordnet werden können, werden in einer neuen Relation modelliert.
Daten, die u. U. in mehreren Untertypen vorkommen, kannst du natürlich in der
"Super-Tabelle" speichern.

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 ;)
jepp ;-)
(Gut das ich nachgefragt habe ;-))))

Naja, du kennst mich ja => Schönheitsfanatiker :-)

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.
Das ist ja nicht das Problem - wieviel Platz braucht NULL? Wenn ich damit Rechne das ich im Schnitt 70% der Spalten nicht brauche, dann wird es doch am Ende drauf hinaus laufen, dass ich vielleicht 20, vielleicht 30 % merh speicherplatz bracuhe - wenn überhaupt. Das ist bei meienr Anwendung vollkommen irrelevant, wenn es das Speicherplatz-Problem an sich ist. Es ist um den Faktor 1000 mehr Speicherplatz verfügbar, als zu Zeit genutzt wird. Und auch Performance ist kein wichtiger Faktor, da es sich um nichtmal 1000 Datensätze handelt. Es geht vor allem um Dinge wie Datenintigirität, Stabilität, Erweiterbarkeit, einfach zu handelnde Datenstruktur... und nicht zuletzt um eine gute, funktionale Datenstruktur.

Du brauchst mich nicht zu überzeugen; am Ende musst du damit leben können ;-)
Wenn du dir sicher bist, dass dies so funktioniert und keine Nachteile auf die
Lebenszeit des Projektes entstehen, dann ist es OK. Soviel ich jetzt davon verstanden
habe, kannst du glaub ich beides ausschliessen; also los! :-)

Zur Zeit habe ich noch ein Problem damit für jede Objektart eine Extra-Tabelle zu erstellen, nicht weil ich Angst vor vielen Tabellen habe, sondern das es unüberschaubarer wird, ich habe ein anderes Projeklt mit knapp 100 Tabellen, alles schön Relational mit vielen sehr tiefen Joins, das ist manchmal ganz schön kompliziert!

Naja, das ist ja ein altes Thema  "schöne, redundanzfreie Modellierung" vs. "Performance
und Einfachheit". Die Lösung liegt irgendwo in der Mitte.

Die Sache hier  ist, das sich alle Objekte bis zu einem Bestimmten Grad von den Attributen nicht unterschieden, und dann wird nach Typ unterschieden, und bei einem kleinen Teil der Attribute dann wieter nach Land, und bei noch ein paar Attributen nach Miete/Kauf.

Wenn ich dann mal alle Kombinationsmögichkeiten ausrechne:

3 Länder
8 Typen
2 (Miete/Kauf)

Brauche ich für die eigentlich ähnlich strukturierten Immobilien-Objekte knapp 50 Tabellen. Wenn ich jetzt mal an allen was ändern will, was eigentlich überall gleich ist, wird das schwer!

OK. Bin mir zwar nicht sicher, ob das genau das ist, was du vorgeschlagen hast, aber:
Warum schmeisst du nicht alle gleichen Attribute in eine Tabelle und alle anderen, die
von irgendwas abhängen in eine andere? - So hast du die Redundanz zumindest in der
"Super-Tabelle" ausgeschlossen.

Viele Grüsse

Philipp

[Lude]

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

[Andreas Korthaus]

Hallo!

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).

;-)

Das ganze ist sogar noch komplexer, ich habe es schon vereinfacht. Was noch dazu kommt, ist das es sich bei diesem Projekt um jenes handelt, wofür ich die 3(eigentlich 4) nur über eine nicht ständige Internetverbindung verbundenen Datenbanken verwende, die sich gegenseitig über den mit einer Standleitung angebunden Web-Server synchronisieren sollen, und das alles natürlich komprimiert und verschlüsselt, eine nette Aufgabe sag ich Dir! Ist aber ein Herausforderung und macht viel Spaß.
Naja, jedenfalls habe ich auch das die ganze Zeit im Hinterkopf udn hatte daher Angst vor zu vielen Tabellen, denn das wirkt sich auf auf die Synchronisation aus, habe ich gedacht, aber eigentlich ist dasja total egal, ich komme eh nicht mit einr Tabelle aus, udn ob ich jetzt 3 große Tabellen habe oder 30 kleine ist im Prinzip total egal und sollte sich gleich gut synchronisieren lassen.

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.)

Tja, manche sind sich sehr ähnlich, manche sind sich sehr verschieden. Die Gemainsamkeiten kommen direkt in die obere Objekttabelle, und alles weitere für jeden Typen in eien spezielle Untertabelle, das wird schon gehen.
Mich würde aber trotzdem interessieren was Du von meinem letzten Ansatz hälst, den ich zur zeit favorisiere: [pref:t=37926&m=207801]

• kannst Du Deine Machtposition mit einer falschen Implementierung ausbauen? (Oder bringt es Geld?)

Hä? Machtposition ausbauen bei falscher Implementierung? Wie soll das denn gehen?

• wird die Loesung wartungsfrei werden, weil ein anderer sich darum kuemmern muss?

genau das ist das Problem, aber das habe ich denke ich immer berücksichtigt, oder wo siehst Du das evtl. eine Wartung nötig wird?

• laesst sich da i.p. Wiederverwertbarkeit was machen? (Also dann bitte "profikorrekt" designen.)

Schwer zu sagen, ist schon _sehr_ speziell das ganze, vielleicht ein paar Module, Datenbank-Synchronisation kann ich sicher nochmal woanders gebrauchen...

Interessante Problematik.

Finde ich auch!

Vielen Dank und viele Grüße
Andreas

[Lude]

Hi,

• kannst Du Deine Machtposition mit einer falschen Implementierung ausbauen? (Oder bringt es Geld?)
  Hä? Machtposition ausbauen bei falscher Implementierung? Wie soll das denn gehen?

nur eine zynische Einzelmeinung. Allerdings habe ich die Erfahrung gemacht, dass der ganz dulle Entwickler, der beispielsweise redundant codiert oder ganz abartige Implementierungen fuer angemessen haelt, in bestimmten Strukturen (Geschaefts- oder Hirarchiestrukturen) absolut erfolgreich ist und seinen Einfluss (er zieht dulle Entwicklerkollegen schwammartig an, generiert Geheimwissen und und und) kontinuierlich ausbaut. - Deine Idee, die letztendlich auf einen Missbrauch relationaler Datenhaltung hinauslaeuft, hat dieses gewisse Etwas, was nach Erfolg riecht.

• wird die Loesung wartungsfrei werden, weil ein anderer sich darum kuemmern muss?
  genau das ist das Problem, aber das habe ich denke ich immer berücksichtigt, oder wo siehst Du das evtl. eine Wartung nötig wird?

Bei dem, was Du vorhast, wird Wartung noetig. Spaetere Anpassungen sind ohnehin "vorprogrammiert". - Wenn ein anderer den Mist spaeter warten musst, kannst Du "befreiter" konzipieren und die eine oder andere Schweinerei implementieren. - Man wird es Dir moeglicherweise spaeter mit einem guten Angebot danken.

• laesst sich da i.p. Wiederverwertbarkeit was machen? (Also dann bitte "profikorrekt" designen.)
  Schwer zu sagen, ist schon _sehr_ speziell das ganze, vielleicht ein paar Module, Datenbank-Synchronisation kann ich sicher nochmal woanders gebrauchen...

Wiederverwertbarkeit beim DB-Design und beim Datenzugriff ist "eigentlich" ausgeschlossen. Eine robust laufende Daten-Replikation mit verschiedenen Datenhaltungen, hmmm, eine echte Herausforderung.

Huendische Gruesse,
Lude