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