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