nicht angemeldet
Hallo Swen,
Das Datenbankschema von srob ist grausam! Das muß anders gehen.
Nein, das ist nicht grausam, sondern die zugrundeliegende Struktur der Daten, sozusagen speicherplatzoptimiert. Alle Daten, die man für die Abfrage braucht, stehen sowieso schon in der Datenbank, weil in jedem vernünftigen Shop die einzelnen Artikel einer Bestellung in sowas wie kunden_artikel gespeichert werden.
Alles, was dann noch kommt, ist Performance-Optimierung durch Caching, entweder durch zusätzliche Tabellen in der db, oder durch die Generierung irgendwelcher Dateien.
Dann ist nur noch die Frage, ob es schneller geht, wenn bei jeder Bestellung die entsprechenden Datensätze in irgendeiner Cache-Tabelle aktualisiert werden. Denn dazu braucht man dann wieder so einen select wie mein Beispiel, und mindestens einen Insert oder Update.
Und, meine (zugegeben etwas ketzerische) Standardantwort: in 90% der Fälle ist ein zusätzlicher Prozessor und ein paar Bänke RAM billiger und effektiver als ein Programmierer, der sich Gedanken über das Caching von Datenbanken macht, die für solche Sachen gemacht und optimiert werden. (Wie gesagt, 90% der Fälle, nämlich die, wo sich die Antwort wie hier mit einem einzigen recht unkomplizierten select rausfinden läßt, beim db-design nicht gepfuscht wurde, und die Zugriffszahlen nicht astronomische Höhen - >50k pro Tag - erreichen).
Falls die Zugriffszahlen wirklich extrem hoch sind, würde ich sowieso die Produktseiten als "statisches PHP" cachen (die sessionids müssen ja immer noch dynamisch erzeugt werden), dann braucht es keine Sonderbehandlung für die "Kunden, die x kauften..."-Links, und der Aufwand für die Generierung der gecachten Seiten ist gegenüber den Zugriffen in der Regel vernachlässigbar.
Aber nachdem ich zum Wohle aller hoffe, daß Bücherbestellungen andere Größenordnungen als Whiskeybestellungen haben (nicht, daß da jetzt noch mehr pidgin-englisch auf uns zukommt...), würde ich meine Standardantwort auch hier anwenden ;-).
Viele Grüße
Stephan