Optimale Struktur?

Hi Leute,
ich muß ein Programm, daß ich geschrieben habe auf DB umstellen.
Die Daten werden langsam sehr groß (>500MB), obwohl ich noch im
Entwicklungsstadium bin.
Das führt mich direkt zum rsten Problem. Ich muß auf Performanz achten.
Aber das eigentliche Problem ist, daß ich meine bisherigen Strukturen
in eine Datenbank gießen muß.
Die Theorie ist mir vertraut, praktisch habe ich noch keine Datenbank
selbst entworfen (keine Kommentare bitte an dieser Stelle).
Mein Problem ist, daß ich nicht weiß, wo ich anfangen soll, da mir
immer mehr Eventualitäten einfallen, die ich beachten müßte.
Vorab ist halt die Performanz das wichtigste, was bedeutet, daß
ch die DB möglichst optimiere (-> Normalformen).
Es Handelt sich um ein Programm zur Aktienanalyse...
So hier nun mal ein paar Fragen:
1. Ich habe streng genommen bereits drei eineinmalig identifizierende
Schlüssel zu speichern (WKN,ISIN,TickerSymbol), soll ich
hier nun einen als Primärschlüssel heranziehen, oder lieber einen
laufenden Schlüssel vergeben (Thema autoincrement) - hat
das evtl. Vorteile?
2. Jetzt mal apstrakt:
Wenn ich nun eine Liste (ID,Name,Lager)
einpflege, aber zu jedem Artikel noch eine
Liste aus EK, Volumen und Datum einpflegen muß,
bedeutet das, dass ich die Tabelle ID,Name,Lager
sowie zu jeder ID eine eigene Tabelle mit EK, Volumen und Datum brauche?
Oder einfach alles in eine Tabelle (ID,EK,Volumen,Datum), denn
für jede ID eine Tabelle wird recht groß, wäre aber nach Codd und
evtl. für die Performanz das Beste, oder?
Habe ich dann meine Schuldigkeit gegenüber Herr Codd getan?
Ist das jetzt ideal?
Hierzu die Zusatzfrage: Kann man hier mit Timestamps arbeiten,
wenn ja wie?
Sollte ich zusätzlich noch über eine Tabelle der Lager gehn?
Wie krass wird das mit der Abfrage, was sagt die Rechenzeit dazu?
Abstraktes Bsp.:
ID Name Lager
010 Bla Lager1
-> EK Volumen Datum
10? 10 1.1.01
20? 5 2.1.01
...
022 BlaBla Lager1
030 JaJa Lager2
004 USW Lager2

Re: Optimale Struktur?

Oliver Bleckmann schrieb:
....
> Die Theorie ist mir vertraut, praktisch habe ich noch keine Datenbank
> selbst entworfen (keine Kommentare bitte an dieser Stelle).
> Mein Problem ist, daß ich nicht weiß, wo ich anfangen soll, da mir
> immer mehr Eventualitäten einfallen, die ich beachten müßte.
> Vorab ist halt die Performanz das wichtigste, was bedeutet, daß
> ch die DB möglichst optimiere (-> Normalformen).
> Es Handelt sich um ein Programm zur Aktienanalyse...
> So hier nun mal ein paar Fragen:
> 1. Ich habe streng genommen bereits drei eineinmalig identifizierende
> Schlüssel zu speichern (WKN,ISIN,TickerSymbol), soll ich
> hier nun einen als Primärschlüssel heranziehen, oder lieber einen
> laufenden Schlüssel vergeben (Thema autoincrement) - hat
> das evtl. Vorteile?

Welchen Vorteil sollte es haben? Wenn Du sicher bist, dass einer
Deiner drei Werte eindeutig ist (vermutlich meinst Du das, wenn Du
"eineinmalig" schreibst?), dann nimm den doch. Bei Tickersymbolen wäre
ich vorsichtig, die sind vielleicht nur pro Börse eindeutig - die ISIN
aber hat ja gerade die Funktion, die Du willst. Was soll da ein
Autoincrement bringen?

> 2. Jetzt mal apstrakt:

konkret würde ich eher "abstrakt" vorschlagen.

> Wenn ich nun eine Liste (ID,Name,Lager)
> einpflege, aber zu jedem Artikel noch eine
> Liste aus EK, Volumen und Datum einpflegen muß,
> bedeutet das, dass ich die Tabelle ID,Name,Lager
> sowie zu jeder ID eine eigene Tabelle mit EK, Volumen und Datum brauche?

Verstehe ich das richtig: Du hast mehrere Artikel ('Liste' mit ID,
Name und Lager), und zu jedem davon gehören Einträge der Form
EK-Volumen-Datum?

Nein, dann braucht man keine eigene Tabelle. Das würde auch Herr Codd
nicht wollen, denke ich. Sondern Du brauchst *eine* Tabelle, in der Du
eben nicht 'EK-Volumen-Datum', sondern 'ID-EK-Volumen-Datum' speicherst.

> Oder einfach alles in eine Tabelle (ID,EK,Volumen,Datum), denn
> für jede ID eine Tabelle wird recht groß, wäre aber nach Codd und
> evtl. für die Performanz das Beste, oder?

Oder. Die Anzahl gleichzeitig offener Dateideskriptoren ist endlich.
Das ist vielleicht für Dein Ziel der 'Performance' nicht vorrangig,
aber wenn Du keinen Dateideskriptor mehr bekommst, dann steht Deine
Anwendung. Performance = 0.

> Habe ich dann meine Schuldigkeit gegenüber Herr Codd getan?
> Ist das jetzt ideal?

Keine Ahnung. Gibt's Punkte für 'ideal' sein (außer bei Models)?

> Hierzu die Zusatzfrage: Kann man hier mit Timestamps arbeiten,
> wenn ja wie?

Klar. Du kannst immer und überall mit Timestamps arbeiten. Genauso,
wie mit jedem anderen Datentyp. Wenn Du dazu eine Frage hast, solltest
Du sie vielleicht so stellen, dass man versteht, was Du wissen willst.

> Sollte ich zusätzlich noch über eine Tabelle der Lager gehn?

Mit einem Staubtuch?

> Wie krass wird das mit der Abfrage, was sagt die Rechenzeit dazu?

Alle Rechenzeiten, die ich kenne, sagen immer nur begeistert "Ja, Ja,
ich will mehr".

Entschuldige, aber wenn Du stammelst, dann gibt's auch nur gestammelte
Antworten. Rechenzeiten, Performance etc. sind von der HARDWARE
abhängig. Steckt 48 Fantastrilliarden Gigabyte Speicher in Deine
Kiste, dann ist die DB die ganze Zeit im Speicher, und alles ist
rasend fix. Nimm 16 MByte, und das Ding steht praktisch. Lass die
Indizes weg, und jeder Join wird schnarchlangsam.