nicht angemeldet
Hi,
ja. im grunde genommen kann ich dir erst mal grob recht geben. nur weiss ich eben nicht, was dein genanntes beispiel von meinem ersten unterscheidet? die handhabung und funktionsweise einer db ist mir geläufig. einfach schnell ne datenbank basteln hatte ich aber nicht vor. ich wollte mir eben ratschläge einholen, wie ich sie performanter/besser machen kann. schliesslich will ich ja dazulernen ;)
Eben deshalb kommt als erstes die Analyse des Problems. Wenn Du ncht weißt, was _genau_ Du benötigst, fängt das T&E an und Du fummelst Dich tot. Ich kenn' das aus eigener Erfahrung ;-)
sicherlich wird das regal aus sogn. modulen zusammen gebaut. dabei haben die besondere eigenschaften (wie du richtig erkannt hast ;)). diese module haben nun auch die eigenschaften gewicht und preis. diese eigenschaften kommen öfters mehrfach vor. da ich redundanz eigentlich vermeiden wollte, wollte ich wissen ob es sinnvoll ist, die letztgenannten eigenschaften in eine extra tabelle auszugliedern. allerdings gestaltet sich doch dann auch eine pflege recht unübersichtlich... oder?
Das die ganzen Regale aus Modulen bestehen - zumindest Ständer und Bretter - hatte ich schon vermutet ;-)
Du hast aber von Ständern gesprochen. Macht keinen Unterschied? Muß ich Dir Recht geben ;-)
Einige Dinger könntest Du rausnehmen bzw verallgemeinern, wenn diese Dinger tatsächlich redundant sind. ("redundant" ist nicht unbedingt gleichbedeutend mit "mehrfach"). So könntest Du z.B. die Unterscheidung in Farben rausnehen, wenn die unterschiedlichen Farben in den jeweiligen Färbungsarten (Pulverbeschichtet, Einbrennlackiert, Schleiflack etc) gleich sind. Wie heißt das immer so schön:"In allen RAL Farben erhältlich" ;-)
Jetzt hast Du aber z.B. die Stelle, wo es möglich ist die Module einmal nur verzinkt, verzinkt und lackiert und nur lackiert anbieten zu müssen. (Blödes Beispiel, aber Du weißt, was ich meine, oder? ;-)
Wenn das oft genug vorkommt, kannst Du das entfernen und ausrechnen (Verzinkt wird z.B. nach Gewicht, das hast Du ja).
Also eine kleine Tabelle mit Aufpreisen erstellen (kann direkt in PHP sein, würde ich der flexibilität wegen aber auch in die DB basteln. Getrennte Tabelle ist hier evt günstiger, je nachdem, wie sich die Preise so ändern):
Modul X = 12,50 EUR, 2,5 kg
verzinkt += 1,50 EUR/kg (evt noch + 0,1 kg Gewicht?)
lackiert += 1,90 EUR/kg
pulverbe += 2,00 EUR/kg
Wenn Du diese Aufteilung nicht hast (wird alles so fetig geliefert mit Festpreisen) sind diese Details nicht mehr redundant, sondern gehören zum Artikel. Auch wenn es die gleichen sind.
Ohne _genaue_ Kenntnis der Daten (genaue Preise wären Dein Geschäftsgeheimnis, aber auch irrelelvant) kann ich wirklich nur so allgemein bleiben.
Wenn ich es wüßte, könnte ich Dir auch sagen, ob es sich lohnt, das führende Adkjektiv des Ausdrucks "relationale Datenbank" beim Wort zu nehmen und die Daten in mehr oder weniger viele kleine, untereinander verbundene Tabellen aufzuteilen.
Ein simples "Redundanzen auslagern" ist nicht sonderlich wirkungsvoll, eher kontraproduktiv. Wenn Du in eine große Tabelle alle Spielarten reinpackst und lagerst dann alle gleichen Preise und Gewichte aus, spart nicht viel, erhöht wahrscheinlich nur unnötig die Komplexität.
Es sei denn:
Das Du nur _sehr_ wenige Gewichts- und Preisklassen hast. Dann kannst Du in einen Integer (also eine Spalte statt zwei) beide Klassen reinpacken und eine zweite Tabelle abfragen. Wenn Du dann auch noch alle weiteren Redundanzen rausschmeißt, wäre es evt möglich, die ganze DB im RAM zu halten, was einen erheblichen Geschwindigkeitsvorteil ergibt. (Das mußt Du bei modernen DBs übrigens nicht mehr extra angeben, das optimieren die von sich aus. Nur müssen die Tabellen halt klein genug sein in den RAM zu passen)
Es kann also nicht allgemein beantwortet werden, ob die Daten von den Regeln streng getrennt werden, oder ob es sich evt lohnt, einige oder gar alle der Regeln vorzufertigen. Bei einer geringen Anzahl an Permutatinen könnte sich das lohnen, aber die Frage ist: was genau ist "gering"?
Aber Du könntest natürlich auch mal schauen, was die Konkurenz so treibt. Ich tue das mal für Dich und nehme mir den Ikea Katalog zur Hand, da sind ja auch Regalsysteme drin ;-)
Da stehen gelistet: Größe, Oberfläche, Preis. Unten drunter und nicht in der Liste: Aufschlag für $WWI. ($WWI = 'Was Weiß Ich' ;-)
Regalsystem Hältvil:
2mx0,8mx0,5m (HxBxT) Kiefer,furniert 26,95
-"- rot,blau 25,95
-"- weiß 24,95
2mx1,6mx0,5m (HxBxT) Kiefer,furniert 49,95
-"- rot,blau 48,95
-"- weiß 47,95
Aufschlag für lesbare Aufbauanleitung: plus 10,00
Jetzt hättest Du folgende Möglichkeiten, das in eine DB zu packen (Für die drei Dinger natürlich nicht, ist nur zwecks Simplifizierung):
Einmal komplett aufgerollt:
Hältvil 2mx0,8mx0,5m (HxBxT) Kiefer,furniert 26,95 10,00
Hältvil 2mx0,8mx0,5m (HxBxT) rot 25,95 10,00
Hältvil 2mx0,8mx0,5m (HxBxT) blau 25,95 10,00
Hältvil 2mx0,8mx0,5m (HxBxT) weiß 25,95 10,00
Hältvil 2mx1,6mx0,5m (HxBxT) Kiefer,furniert 26,95 10,00
Hältvil 2mx1,6mx0,5m (HxBxT) rot 25,95 10,00
Hältvil 2mx1,6mx0,5m (HxBxT) blau 25,95 10,00
Hältvil 2mx1,6mx0,5m (HxBxT) weiß 25,95 10,00
Vorteile: Nur Abfrage der DB nötig, keine große Rechenleistung.
Nachteile: braucht viel Platz und komplexe Abfragetechnik, letzteres kann die eingesparte Rechenleistung wieder auffressen.
Das ist jetzt Dein Grundgerüst, das würde funktionieren, _erst_ jetzt kannst Du optimieren. Zunächst einmal nachschauen, wo denn die Redundanzen liegen. Ein, wenn auch nicht immer zutreffendes Merkmal einer Redundanz ist das mehrfache Vorkommen von Werten. Hier sind es: der Name, die Größe und der Aufpreis. Außerdem ist da zweimal der gleiche Preis, das merken wir uns schon mal vor.
Der Aufpreis kann als das behandelt werden, was er ist: ein Aufpreis.
Korrekterweise ist so eine Anleitung nur einmal nötig, aber das ignorieren wir mal und schieben das auf das beschissene Beispiel ;-)
So ein Aufpreis ist eine einfache Addition, das kostet nicht viel rechnleistung also nehmen wir das mal ganz aus der DB raus und lassen das die Maschine machen. Schon ist eine Spalte ganz verschwunden.
Was können wir noch vereinfachen? Lesen wir doch drei Reihen einmal laut vor:
Das Regal "Hältvil" in der Größe 2mx0,8mx0,5m kostet in der Ausführung rot 25,95.
Das Regal "Hältvil" in der Größe 2mx0,8mx0,5m kostet in der Ausführung weiß 24,95.
Das Regal "Hältvil" in der Größe 2mx1,6mx0,5m kostet in der Ausführung rot 48,95.
Als fester Wert ist hier der Name des Regals vorhanden, als variable Werte einmal die Größe und einmal der Preis, alles andere bleibt in der Beziehung gleich. Also können wir da mehrere Tabellen rausmachen, wie das in der "aufgerollten" Variante bereits intuitiv ersichtlich war. (Ist aber natürlich nicht unbedingt _jedesmal_ so intuitiv ersichtlich ;-)
Einmal:
Hältvil 2mx0,8mx0,5m ID(Hältvil,Größe-1)
Hältvil 2mx1,6mx0,5m ID(Hältvil,Größe-2)
(ID() ist eine Identifikationsnummer)
Und zum zweiten:
ID(Hältvil,Größe-1) Kiefer,furniert 26,95
ID(Hältvil,Größe-1) rot 25,95
[...]
ID(Hältvil,Größe-2) Kiefer,furniert 49,95
ID(Hältvil,Größe-2) rot 48,95
[...]
Nach dem altem Motto "rinse, repeat", nochmal das Selbe und wir sehen, das die zweite Tabelle ebenfalls gesplittet werden könnte. Ob sich das lohnt ist eine andere Frage. Bei sehr vielen Größen _und_ sehr vielen Oberflächen: vielleicht.
Nun gibt es da aber ncht nur ein Regal, sondern - Geschmäcker sind bekanntlich verschieden - viele verschiedene Designs:
Hältvil, Hältnits, Knürscht, Anita, Ekbert ...
Die kannst Du nun einfach in die erste Tabelle mit reinpacken, oder noch eine Tabelle darüber packen, die nichts als die Namen enthält und einen "Link" zu der Größentabelle.
Du siehst: was redundant ist, entscheidet weniger die Mehrheit als die Zusammengehörigkeit und das erlaubte Maß an Komplexität. (Je simpler, desto besser. Erst wenn dieses Konzept nicht mehr den Anforderungen entspricht (Meistens Geschwindikeitsprobleme) optimieren.) Einfach alle mehrfach vorkommenden Preise und in Deinem Fall auch Gewichte auslagern bringt es nicht.
Hier kommen auch wieder die blauen und roten Regale zum Zuge: kosten beide das Gleiche, habe ich aber nicht mehr ausgelagert. Warum nicht? Sind nur zwei Stück, das lohnt nicht.
Habe ich Dich jetzt ausreichend verwirrt? Ja? Wolltest doch nur wissen, ob es sich lohnt, Preis und Gewicht auszulagern und bekommst zweimal(!) so einen Sermon serviert? Tja, Datenbanken sind ein sehr komplexes Thema, meistens erfordert auch eine scheinbar simple Frage eine langwierige Antwort, die Dir am Ende doch nicht _direkt_ helfen kann.
Es gibt einige allgemeine Bücher zum Thema relationale Datenbanken. Schau einfach mal bei O'Reileigh (Da weiß ich nie, wie man die schreibt und von hier aus seh' ich das Regal nicht, bin zu kurzsichtig ;-) oder Amazon und nimm Dir ein Wochenende Zeit.
so short
Christoph Zurnieden