große datenbank, oder viele abfragen?

[Christoph Zurnieden]

Hi,

Hat ein wenig länger gedauert, aber wenn ich schonmal meine etwas Zeit zu haben ... ;-)

ich muss anhand der belastung zunächst mal den richtigen ständer finden. es gibt aber zig möglichkeiten.
konstanten eines ständers wären:

• höhe
• fußtiefe
• ipe (profil)
• bauart (einseitig, doppelseitig)
• oberfläche (lackiert, verzinkt)
• befestigung (geschraubt, gehangen)

Wenn die Ständer zusammengebaut werden, sind das keine Konstanten, sondern Variablen. Nur und wirklich _nur_ die kleinsten Teile sind Konstanten, alles andere baust Du ja zusammen.
(Etwas vergröbert, da Du wahrscheinlich Schrauben und Muttern nicht unbedingt mit reinhauen mußt, kannst Du ja danach besser berechnen, statt den Wert vorzuhalten.)

anhand dieser merkmale möchte ich folgende werte ermitteln:

• gewicht
• preis

Das rechnest Du aus, das kommt nicht in die Tabelle, ist das so korrekt?

würde ich eine tabelle nur mit (gleich mal mit bsp-werten):

• höhe (1500-6000) -> smallint
• fußtiefe (800-3400) -> smallint

[...]

und eine tabelle mit:

• gewicht (0.00 - ...) -> decimal(10,2)
• preis (0.00 - ...) -> decimal(10,2)

würde ich garantiert weniger platz verbrauchen, als wenn ich die zweite tabelle in der ersten zusammenfasse (was ich wegen meiner faulheit auch vorhaben werde - doch ich lass mich gern eines besseren belehren).

Also zusammenfassend:

Du baust Regalständer aus Modulen zusammen. Diese Module gibt es in den verschiedensten Ausführungen. Wenn Du alle Module für einen bestimmten Regalständer zusammenrechnest bekommst Du Gewicht und Preis. Ist das so korrekt?
Gut.
Jetzt möchtest Du aus welchen Gründen auch immer alle Kombinationen vorhalten. (Naja, Festplattenspeicher ist billig, warum auch nicht)

nun mach ich mir deswegen sorgen, weil's nicht einfach so ne pille palle tabelle wird, sondern da kommen mal schnell 500.000 einträge  für die ständertabelle zu stande (jede menge ständer ;) ) und das wäre dann erst die erste tabelle...

Das spielt doch im Grunde genommen keine Rolle, die Suchzeiten sind bei einer Datenbank gleich, ob Du nun 500 oder 500.000 Einträge hast.
(Ja, ich weiß, aber der Unterschied ist wirklich minimal, wenn die Datenbank vernünftig gebastelt wurde).
Nur, wenn Du in der Datenbank selber suchen mußt, wird's kompliziert. Also sorgfältig planen, wo der Index sitzen soll (MySQL unterstützt AFAIK nur einmal Index, lasse mich aber gerne eines Besseren belehren, bin nicht ganz auf dem Laufenden)

ums vorweg zu nehmen: die werte bauart, oberflaeche, befestigung würde ich schon so bauen, das nur "1" oder "2" drin steht, diese kann ich dann später per array wieder "nachtragen". da es sich nur um 2-3 werte handelt, will ich nicht unbedingt die db damit strapazieren.

Warum redest Du da von strapazieren? Genau für sowas ist ein DB da: viele Daten schnell greifbar zu halten.

Es ist ja meistens so, das Du Dir dafür einen kleinen Server anmietest, der hat jede Menge Festplattenplatz, aber nur eine begrenzte Menge Rechenkraft. Ich würde also soviel wie möglich in die DB auslagern.

Alles ein wenig durcheinander, deshalb hier noch eine Zusammenfassung (Die allerdings zu einem anderem Schluß kommt ;-):

Du baust Regalständer aus Modulen zusammen.
Die Module haben als Eigenschaften Preis, Gewicht, Größe (nehme mal an, das es ein paar verschiedene sind) und "Aussehen" (Material, Struktur, Farbe etc). Ich nehme an, das die Statik der Module jeweils gleich ist, wenn nicht gehören diese Werte auch noch mit rein.

Damit hättest Du eine Handvoll Module, die genau beschrieben sind.
Aus einer diskreten Anzahl Module (teilen kann man die nicht, oder? Es werden immer nur ganze Module benutzt?) baust Du dann Regalständer zusammen.

Dieser Zusammenbau geschieht nach Regeln.

Du suchst: Preis und Gewicht. Beide Werte ergeben sich aus Anzahl und Art der Module. Auch eine Regel.

Du hast also auf einer Seite die Daten (Welches Modul) und auf der anderen Seite die Regeln (Ständer besteht aus x Modulen der Art Y wenn das Dingen soundso groß sein soll, sowie: Preis und Gewicht, die ergeben sich aus der Anzahl der Module der Art Y)

Die Daten gehören in die DB (Heißt ja auch: _Daten_bank ;-), die Regeln führst Du dann mit PHP aus.

Ein Beispiel:
Der Kunde bestellt ein Regal der Größe 3x5x1m, 3 Bretter, Fachlast max 100kg/m^2, Stützlast Boden punktuell max 250kg/cm^2.
Die Aufgabe von PHP, nein, die vom Programmierer natürlich ;-), ist es, anhand dieser Daten die erforderliche Art und Anzahl an Modulen zu errechnen. Der Kunde möchte nun seine Ständer gerne in RAL 3000 (Feuerwehrrot) haben und zwar Pulverbeschichtet. Jetzt kannst Du mit PHP an die Datenbank gehen, das Modul Y in der passenden Farbe und Größe raussuchen und Preise und Gewichte addieren. Anhand einer kleinen Tabelle, zu beziehen von Deinem $SPEDITEUR, kannst Du dann auch gleich das Porto errechnen.
Wenn Du auch Aufbau mit anbietest wahrscheinlich auch gleich die Montagekosten. (Hängt aber von mehr Faktoren ab, deshalb die Einschränkung)

Und schon wird aus einer Riesentabelle, die übrigens nur sehr aufwendig zu erstellen gewesen wäre, eine recht kleine und noch ein wenig Hirnakrobatik um die Algorithmen in PHP umzusetzen.

Noch Fragen?
Wahrscheinlich nehme ich mal an ;-)
Gerne hier.

so short

Christph Zurnieden