Varianten im Backend generieren sinnvoll?

Hallo, Irgendwie leuchtet mir das Generieren der Varianten nicht ein. In anderen Systemen muss im Backend nichts vorberechnet werden. Diese Methode bläht doch nur die DB auf. Gibt es im Frontend überhaupt noch Daten die nicht fix aus der DB geladen werden? Ist ja schließlich schon alles vorgekaut. Welchen Vorteil hat also diese Methode gegenüber der on-the-Fly Berechnung?

Jede Variante hat aber Ihren eigenen Preis, Freitextfeld, Bild, Händlerpreis etc. etc. Wie möchtest du das denn “on-the-fly” im FE machen? Geht ja garnicht ohne DB :wink:

Hallo Ralph, die Erstellung der Varianten geht eigentlich ganz gut von der Hand. Und für Produktexporte und ähnliches ist das notwendig. Ich kenn das noch von XTCommerce - das hat richtig Zeit beansprucht und war nur halb so umfangreich.

Mit xt:c ist ein “gutes” Beispiel. Da wurden im Backend nicht erst tausende Varianten-Kombinationen berechnet. Im Frontend bei diesen Systemen wird der Gesamt-Preis plus eventuell gewählter Aufpreis-Optionen otF kalkuliert. #sahfde Definiere mal viel Zeit in dem Zusammenhang. Das anlegen der Varianten und der Zugehörigen Bilder etc. muss ich auch in SW durchführen. Also erst einmal gleicher Aufwand. #kayyy All das wird in den anderen Systemen auch in der DB abgebildet. Aber warum müssen dann noch zusätzlich alle Varianten Möglichkeiten - das können schon einmal über 1000 werden - zusätzlich in der DB abgelegt werden? Das ist dann doch nur Ballast. Und dann beim Variantenwechsel jedesmal die DB durchlaufen um herauszufinden welche Kombination nun darauf passt. Ich denke das dauert länger (das scheint auch der langsame Variantenwechsel im FE zu bestätigen) als die Parameter gleich in ein Array einzulesen und dann je nach Wahl zu kombinieren.