Du säger inte riktigt vad du har för bakgrund och hur mycket du kan om programmering och databasdesign . Det låter som att du borde läsa lite. Konceptuellt även om din design är ganska enkel. Din beskrivning identifierar bara två enheter:
- Finansiellt instrument; och
- Citat.
Så du måste sedan identifiera attributen.
Finansiellt instrument:
- Säkerhetskod;
- Marknad;
- osv.
Citat:
- Tidsstämpel;
- Finansiellt instrument;
- Budpris; och
- Fråga pris.
Referensen till det finansiella instrumentet är vad som kallas en utländsk nyckel . Varje tabell behöver också en primärnyckel , förmodligen bara ett fält för automatisk ökning.
Konceptuellt ganska enkelt.
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'
Om din datauppsättning är tillräckligt stor kanske du vill inkludera (bud + fråga) / 2 i tabellen så att du inte behöver räkna direkt.
Ok, så det är den normaliserade vyn. Efter detta kan du behöva börja göra prestandaoptimeringar. Fundera på den här frågan om lagring av miljarder rader i MySQL . Partitionering är en funktion i MySQL 5.1+ (ganska ny).
Men en annan fråga att ställa dig själv är denna:behöver du lagra all denna data? Anledningen till att jag frågar detta är att jag brukade arbeta med onlinemäklare och vi lagrade bara alla affärer under ett mycket begränsat fönster och affärer skulle vara en mindre uppsättning data än offerter, vilket du verkar vilja ha.
Att lagra miljarder rader med data är ett allvarligt problem och ett du verkligen behöver hjälp med att lösa.