Du siger ikke rigtig, hvad din baggrund er, og hvor meget du ved om programmering og databasedesign . Det lyder som om du burde læse lidt. Konceptuelt selvom dit design er ret simpelt. Din beskrivelse identificerer kun to enheder:
- Finansielt instrument; og
- Citat.
Så du skal derefter identificere attributterne.
Finansielt instrument:
- Sikkerhedskode;
- Marked;
- osv.
Citat:
- Tidsstempel;
- Finansielt instrument;
- Budpris; og
- Spørg om pris.
Referencen til det finansielle instrument er det, der kaldes en fremmednøgle . Hver tabel har også brug for en primær nøgle , sandsynligvis bare et felt med automatisk stigning.
Konceptuelt ret simpelt.
CREATE TABLE instrument (
id BIGINT NOT NULL AUTO_INCREMENT,
code CHAR(4),
company_name VARCHAR(100),
PRIMARY KEY (id)
);
CREATE TABLE quote (
id BIGINT NOT NULL AUTO_INCREMENT,
intrument_id BIGINT NOT NULL,
dt DATETIME NOT NULL,
bid NUMERIC(8,3),
ask NUMERIC(8,3),
PRIMARY KEY (id)
)
CREATE INDEX instrument_idx1 ON instrument (code);
CREATE INDEX quote_idx1 ON quote (instrument_id, dt);
SELECT (bid + ask) / 2
FROM instrument i
JOIN quote q ON i.id = q.instrument_id
WHERE i.code = 'GOOG'
AND q.dt >= '01-06-2008' AND q.dt < '02-06-2008'
Hvis dit datasæt er tilstrækkeligt stort, vil du måske inkludere (bud + spørg) / 2 i tabellen, så du ikke behøver at regne med det samme.
Ok, så det er den normaliserede visning. Herefter skal du muligvis begynde at lave ydelsesoptimeringer. Overvej dette spørgsmål om lagring af milliarder af rækker i MySQL . Partitionering er en funktion i MySQL 5.1+ (temmelig ny).
Men et andet spørgsmål at stille dig selv er dette:skal du gemme alle disse data? Grunden til, at jeg spørger dette, er, at jeg plejede at arbejde med online-mæglervirksomhed, og vi opbevarede kun alle handler i et meget begrænset tidsrum, og handler ville være et mindre sæt data end kurser, som du ser ud til at ønske dig.
Lagring af milliarder af rækker af data er et alvorligt problem, som du virkelig har brug for seriøs hjælp til at løse.