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