2 Antworten zu diesem Thema

[Algorithman]

Hallo zusammen,

 

Ich habe mir die Datenbankstruktur näher angesehen und dabei ist mir aufgefallen, dass die product-Table dazu verdammt ist, immer weiter zu wachsen.
Da die orderitems per FK an die product table gebunden sind, wird es unmöglich gemacht, die products auch mal aufzuräumen und alte Produkte wirklich aus der Datenbank zu nehmen ohne die order zu zerstören.

 

Und je grösser die product table wird, desto länger werden Suchanfragen etc. brauchen, denn die Indizes wachsen ja mit.

"Gelöschte" Artikel werden ja auch nicht aus dem product_category_mapping genommen, wahrscheinlich auch nicht aus den anderen mappings. Das geht dann natürlich soweit, dass ich nicht mal die Bilder zuverlässig löschen kann, weil auch diese Verweise bestehen bleiben.

 

Da wäre es wirklich besser, wenn die orderitems unabhängig von den products wäre. Ich seh da schon Performance-Probleme auf mich zukommen, die dann nicht zu lösen sind ohne ständig upzugraden. Wir haben einen ziehmlich hohen Durchlauf (mind. 300-400 pro Monat jetzt und soll ja mehr werden) von verschiedenen Produkten.

Andere Shopsysteme flatten dazu einfach die Daten und sehen fertige orders als reinen Datendump. Der darf dann ja auch wachsen, da muss ich nicht immer drüber suchen.

 

Für Nachbearbeitung von Orders würde ich da schon auch die product id hinterlegen, aber eben nicht als cascade und zusätzlich eben alle relevanten Daten, die zur Anzeige der Order für den Kunden oder im Backend nötig sind.

 

Würde mich freuen über Input zu der Problematik von euch.

 

 

MfG

 

Chris

[Murat Cakir]

Bei ordentlicher Server-Konfiguration kannst du Millionen von Produkten verwalten ohne nennenswerte Performance-Einbrüche. Smartstore ist sehr performant und hochskalierbar. Dann gibt es da noch MegaSearch (Lucene) als Plugin, das eine konstant hohe Suchgeschwindigkeit garantiert, egal wieviel Mio Datensätze du hast. Was Medien angeht: wenn Dateispeicherort Festplatte oder gar Azure BLOB ist (und nicht Datenbank, wovon wir eh abraten), spielt die Menge an Mediendateien ebenfalls keine Rolle.

 

Einen Order-Dump werden wir vielleicht irgendwann in Zukunft implementieren, steht aber im Moment auf keiner TODO-Liste. Ist auch relativ aufwändig, weil wir dadurch die Datenintegrität verlieren und viel Code umbauen müssten.

[Algorithman]

Hallo Murat, vielen Dank für die Antwort.

 

 

Folgendes Beispiel: Kunde ordert etwas, Betreiber/Mitarbeiter benennt Produkt um (wissen vielleicht noch gar nicht, dass eine Order existiert), Kunde will danach die Order ansehen/PDF downloaden und bekommt was anderes präsentiert als in seiner Email stand.

 

Der Preis zu diesem Zeitpunkt wird ja fixiert abgespeichert, nur der Produktname (oder was auch immer sonst noch benötigt wird) nicht.

Hat ja einen Grund, warum man den Preis in der orderitems hinterlegt, oder?
Hat man dann als Shopbetreiber eine "unveränderbare" Kopie der Bestellung?. Geht das nicht in die Richtung GoBD?

Hier ein Auszug von einer Seite, die sich mit der GoBD auseinander setzt:
 

Ebenfalls wichtig ist, dass sämtliche Belegdaten nachvollziehbar sind. Darunter ist zu verstehen, dass ein Mitarbeiter einer Behörde sämtliche abgeschlossene Geschäfte, von der Anbahnung bis zum Abschluss, lückenlos nachvollziehen kann. Für Shopbetreiber ist dieser Punkt nicht immer trivial, da häufig mehrere Dienstleister an einer Bestellung involviert sind. Im Onlineshop ist dies z.B. die Bestellung selbst, die entweder im Shopsystem oder per eingehender E-Mail für den Betreiber vermerkt ist. 

 

Warenwirtschaftsprogramme (Lexware etc) und andere Shopsysteme machen das so, dass alles was zum Kunden/Lieferanten geht, festgeschrieben wird, sprich nachdem die Rechnung/Lieferschein/Bestellbestätigung erstellt wurde, führen Änderungen am Artikel nicht zur Änderung an der Rechnung/Lieferschein/Bestellbestätigung.

 

 

 

Ist auch relativ aufwändig, weil wir dadurch die Datenintegrität verlieren und viel Code umbauen müssten.

 

Ich sehe das eher so, dass die Orders dann erst Datenintegrität bekommen werden, nicht verlieren. Momentan sind Orders eben änderbar (z.B. durch unachtsame Mitarbeiter) durch Änderungen am Product-Datensatz (excl. Preis).

 

Änderungen würden sich glaube ich darauf beschränken, wie man mit der ProductId in der orderitems umgeht (double check, 1. existiert Datensatz noch, 2. deleted-Flag) und woher die Daten für die Anzeige der Order genommen werden.

 

Auch eine Neuerstellung einer Bestellung durch den Kunden würde nicht viel aufwändiger, wenn die Produkt-Id immer noch mit gespeichert wird, denn gelöschte Artikel werden da sowieso nicht wieder in den Warenkorb gelegt.

 

 

 

Was die Medien angeht, ich hätte eben gerne bei den MediaFiles geschaut, ob es noch einen Verweis auf diese gibt, wenn nicht, dann kann ich die Datei (nein, ich hab auch nicht geplant, das in der DB zu speichern  ) und den zugehörigen Eintrag ja löschen. Bei uns geht es dabei um 15/30/60 Bilder (je ~1MB plus Thumbnails) pro Artikel. Das summiert sich dann schon schnell und dann spielt die Datenmenge durchaus eine Rolle, will ja nicht alle paar Monate Festplattenplatz dazubuchen müssen.

 

 

Ja, Smartstore ist performant und es ist wirklich super, damit zu arbeiten, auch als Entwickler.

Aber die kaskadierende Abhängigkeit der orderitems zu den products ist etwas, was auch mein Chef (absolut kein IT-Mensch) sofort negativ gesehen hat, als ich ihm davon erzählt habe.

Ich muss jetzt erstmal schauen, ob ich die Speicherplatz-Problematik anders in den Griff bekommen werde, wie gesagt, unbenutzte Dateien würde ich gerne löschen  .

 

 

Mit freundlichen Grüßen

 

 

 

Chris