mysql db erstellen für shopsystem

Hey,
ich bin grade dabei eine DB zu schreiben.
Und zwar soll jeder Auftrag in der DB archiviert werden. Meine Frage ist nun:

Ein Auftrag besteht ja aus x Artikeln. Soll ich nun für jeden Auftrag eine eigene Tabelle erzeugen und dort die Artikel zu dem Auftrag mit den dazugehörigen Mengen auflisten?

Normalerweise würde ich es ja nach den Gesetzen der Normalisierung, also logische Minimierung zur Redudanz, machen. Ich habe nur Angst, dass meine DB dadurch langsam wird, bzw. ich irgendwann keine Datensätze mehr in die Tabelle einfügen kann.

Momentan hab ich folgende Tabelle

Auftragsdaten:

id Auftragsnr Kundennr Artikelnr Menge
1 32482 1 1 3
2 32482 1 2 2
3 32483 2 1 1

Und dann natürlich eine Tabelle Kunden, wo dann die Kundendaten stehen und eine Tabelle Artikel, wo man an die Daten des Artikels kommt.

Ich bin mir nur nicht sicher, ob auf Dauer nicht die Performance darunter leidet, wenn ich je nachdem wie viele verschiedene Artikel zu einem Auftrag gehören, ich dort mehrere Datensätze pro Auftrag in einer Tabelle habe, bzw. ob die Tabelle irgendwann keine Datensätze mehr aufnimmt, weil sie zu groß ist.

Gruß

 

Nein, eine Datenbank ist dafür gemacht viele Einträge in einer Tabelle zu halten. Wichtig bei großen Datenmengen ist lediglich ein sinnvoller Index. Teilst du die Datensätze in mehrere Tabellen auf bewirkst du vermutlich nur eine Verschlechterung der Performance, denn du musst immer erst den Tabellennamen ermitteln und in einen Select einsetzen, ggf. sogar mehrere Selects zusammen führen. Vermutlich gibt es aus speichertechnischer Sicht noch ca. 100 andere Gründe, alles in einer Tabelle zu halten.

 

Servus

Danke. Dann mach ich es nach den Gesetzen der Normalisierung.

Danke für deine Antwort

 

Wenn du archivieren musst, würde ich deine Tabelle um eine Spalte z.B.: "archiv_flag" erweitern, und wenn die Datensätze ein gewisses Alter erreicht haben, würde ich dieses Flag auf "J" setzen, somit grenzt du in der Oberfläche ALTE Daten von aktuellen Daten ab!

Lg

 

Ist ne super Idee. Danke. Das werde ich beim Aufstellen ses E/R Modells berücksichtigen.
Danke

 

Sobald du aber nach Flag, weitere Spalten sortierst in einem Select solltest du auch einen Idex mit Flag, weitere Spalten haben.

 

Also ich hab es so gemacht, dass die Tabelle Auftrag eine Spalte archivid hat. Jetzt gibt es eine Tabelle Archiv. Diese hat die Spalten archivid und archiv.
In der Spalte archiv kann ich dann ja ein Symbol einfügen, welches für die Aktualität des Auftrags steht.

Ist das Richtig?
Oder wie meinst du das ukulele?

Gruß

 

Ich glaube PLSQL wollte nur ein BIT setzen und keine weitere Tabelle anlegen um anhand des BITs die Daten schon vorab aus einem Select ausschließen.

Wenn du Daten in eine Archivtabelle schreibst (was ja durchaus auch kein Problem ist), macht es ja keinen Sinn, die Daten auch noch in der Haupttabelle zu belassen. Das Archiv-Bit oder eine ArchivID wären also sinnfrei. Es sei denn du willst eine Versionierung oder einen Verlauf des Datensatzes aufbauen, aber auch da gibt es platzsparendere Methoden.

Was ich meinte (Aufbau eines Indexes mit der Spalte Archiv-Bit) dient der schnellen Abfrage bei Verwendung der Spalte in einem Select und hat nichts mit der Datenhaltung als solche zu tun. http://de.wikipedia.org/wiki/Datenbankindex

 

okay. Denk ich habe es verstanden.
Danke nochmal

 

Hey,

genau ukulele, ich wollte nur ein BIT setzen um im täglichen Betrieb (das dafür verantwortliche Select-Stmt) Archivdaten auszuschließen.

Du schreibst ja weiter oben, dass datenbanktechnisch keine Einwände bestehen, sofern ein Index ab einer gewissen größe verwendet wird, wenn ALLE Daten weiterhin in der gleichen Tabelle stehen!!! (hier bin ich voll bei dir)

Lg