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