Frage zu Online Shop Datensicherung

Hallihallo,

bin gerade dabei den Schluss eines Online Shops zu programmieren und dabei bin ich mal wieder auf ein kleines Problem gestoßen.

Ich habe eine Datenbank kreiert, bei der Eingetragen werden, welche Zahlungsart, ID zur Rechnungsadresse usw.!

Wäre es nicht schlauer keine ID anzugeben, sondern den Inhalt selbst, da dieser ja vom Benutzer gelöscht werden kann.

Stellen wir uns mal vor ein Benutzer trägt eine Rechnungsadresse ein, bestellt mit dieser, löscht aber gleich danach diese Rechnungsadresse. Wenn der Admin dann schaut, wo er die Rechnung hinschicken will findet er sie nicht. Also wäre es doch schlauer einfach das ganze ohne ID sonder direkt als Text zu speichern. Eine andere Möglichkeite wäre natürlich, dass Löschen des Benutzers zu verhindern, dadurch würde aber eine Datenbank leicht vollgestopft werden.


Hat irgendjemand Vorschläge?
 
Nur weil der Nutzer etwas loescht, muss das noch lange nicht heissen, dass das auch aus der DB verschwindet. Du koenntest z.B. ein alive-Flag, oder deleted-Flag einfuehren.
 
Nein, das machst du nicht...

Aber ich hätte einen anderen Vorschlag für dich. Lege doch einfach eine eigene Tabelle für Bestellungen an. In diese Tabelle schreibst du dann alles relevante zu einer Bestellung rein. Auch die Lieferanschrift, etc.

Und zum Schluss noch ganz kurz etwas zu Datenbanken und dem "vollstopfen": Heute leben wir in einer Welt, in der Daten das einzig wichtige sind. Nur deshalb haben wir hochperformante Datenbanken. Denn heute ist so etwas möglich und was möglich ist, dass sollte man auch nutzen. Denn je mehr Daten man speichert, desto mehr kann man später damit machen. Ich habe z.B. bei mir auf einem Server eine Datenbank mir rund 40 Mio Einträgen, knapp 5GB sind es auf der Platte. Letzten monat habe ich die Datenbank kein einziges Mal benutzt (zum Lesen), diesen Monat nur drei Mal. 99,9995% der Daten der Datenbank brauche ich nicht. Doch ich weiß, dass die Daten da sind und ich die jederzeit nutzen kann.
 
Möchte mich port29 anschließen. Speicher ist heute so spottbillig, dass er unendlich bereit gestellt werden kann. Also lieber etwas 2x abspeichern und damit ein paar MB verschwenden als etwas wegoptimieren und sich nach nem Jahr ärgern. Denn nach nem Jahr änderst du aufgrund der Vielzahl an bereits anders abgespeicherten Daten daran eher nichts mehr.
Das einzige was gegen Datenbanken zumüllen spricht ist dass die Zugriffszeit auf eine Datenbank deutlich mit ihrer Größe zusammenhängt. Aber selbst da gibt es Mechanismen und Wege.

Warum man Daten in einer Datenbank nicht redundant abspeichern sollte hat nichts mit doppeltem Speicherverbrauch zu tun, sondern eher mit der großen Gefahr inkonsistenter Datensätze.
Aber auch da ist eine kluge Struktur nicht automatisch die die keine Redundanz aufweist (siehe dein Beispiel).

Ich löse das meist so, dass wichtige Datensätze deren richtigkeit zu einem bestimmten Zeitpunkt zweifelsfrei nachgewiesen werden können muss und an denen es nichts mehr zu ändern gibt in einer separaten Tabelle gespeichert werden. So kann der Benutzer bestellen (Lieferung wird an die zum Zeitpunkt der Bestellung eingetragene Lieferadresse geliefert), direkt im Anschluss Anschrift ändern, wieder bestellen (Lieferung an neue Adresse).
Ich finde es unkomfortabel, dass ein Benutzer nach anlegen seines Accounts eine Lieferadresse oder Rechnungsadresse anlegen muss und diese dann nie wieder ändern kann.
 
Zuletzt bearbeitet:
Ich schließe mich den Ratschlag meiner Vorredner an. Speichere jede Bestellunganfrage samt aller dafür benötigten Daten zusammen mit einem Status in einer eigenen Tabelle.
Den Status kannst du dann dafür verwenden, um, neben einer Rückmeldung für den Benutzer, zu bestimmen, ob die Bestelldaten noch geändert werden können. So könnte beispielsweise während des Status „unbearbeitet“ die Daten noch direkt verändert werden, bei „wird bearbeitet“ oder „versandbereit“ wäre ein Anruf nötig und bei „versandt“ wäre nichts mehr zu machen.
 
Zurück