SQL Datenbankstruktur für Preisverlauf

[Cave Johnson]

Hi,

ich habe eine MySQL-DB mit ~9000 Artikeln. Alle Artikel befinden sich in einer Tabelle mit einer id, artikelnummer und preis. Zusätzlich soll nun der tagesaktuelle Preis gespeichert werden. Pro Artikel kommt also pro Tag ein neuer Preis dazu; ebenso kommen pro Tag ~10-20 Artikel dazu.

Was mach ich nun am besten:

1. pro Artikel eine eigene Tabelle (9000+!?) mit einer neuen Zeile/Tag
2. eine einzige Tabelle mit 9000+ Spalten und einer neuen Zeile/Tag
3. ganz anders -> wie?

 

[trialgod]

Eine Tabelle mit artikel_id, datum und preis?

 

[chriz0101]

ne möglichkeit wäre eine kombitabelle

sprich du machst eine tabelle für den verlauf, mit "id" und preis
und dann machst du eine kombitabelle, dadrin steht die id aus der artikel kapitel und die id aus der preisverlauf tabelle
über join kannst du diese dann darüber verbinden

allerdings weiss ich nicht ob das nicht etwas overpowered ist für eine so kleine datenbank. weil 3 spalten bei 9000 einträgen ist für n sql server ja nichts. alternative wäre punkt 2.

 

[trialgod]

Die Artikelnummer sollte doch schon eindeutig sein? Also einen Index drauf und in der Preisverlauftabelle einen Foreign Key darauf mit Datum und Preis. Warum noch eine Extratabelle?

 

[Yuuri]

Eine neue Tabelle natürlich. Wozu Millionen von Spalten anlegen?

id | datum | artikel | preis

Und einfach die Daten eintragen.

 

[3murmeln]

Da in der aktuellen Tabelle wahrscheinlich die Artikelnummer bereits das eindeutige Kriterium ist (Primärschlüssel), kann man sich die ID sogar sparen.
Die neue Tabelle hätte dann bloß die Spalten Artikelnummer, Datum und Preis - wobei die Artikelnummer + Datum der Primärschlüssel für diese Tabelle wären.

Der SELECT würde dann ungefair so ausseheen

SELECT ...
FROM Artikel INNER JOIN Artikelpreise
ON Artikel.Artikelnummer = Artikelpreise.Artikelnummer
WHERE Artikel.Artikelnummer = ... AND Artikelpreise.Datum BETWEEN ... AND ...

 

[Cave Johnson]

Hm, ... auf das einfachste wollte ich wohl einfach nicht kommen

Danke.

 

[Enigma]

die id ist optional. ich würd den PK (datum,artikel) setzen und so noch einmal 25% Platz in der Tabelle sparen. Unbedingt drauf achten ne reine integer-tabelle zu machen, damit die performance optimal ist:

datum unsigned int,
artikel unsigned int,
preis decimal(10,2)

Im Monitoring sieht das bei uns so aus:

CREATE TABLE `history` (
  `itemid` bigint(20) unsigned NOT NULL DEFAULT '0',
  `clock` int(11) NOT NULL DEFAULT '0',
  `value` double(16,4) NOT NULL DEFAULT '0.0000',
  KEY `history_1` (`itemid`,`clock`)

So brauchen 4,2M rows nur 318 MB Platz + 140 MB Index. Skaliert in anderen Tabellen Problemlos von der Performance auch auf über das 10-Fache.

 

[Daaron]

Eine neue Tabelle natürlich. Wozu Millionen von Spalten anlegen?

Würde eh nicht gehen. MySQL z.B. rennt überraschend schnell ans Spalten-Limit.