Lösung: XML?

[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