Tak naprawdę nie mówisz, jakie masz doświadczenie i ile wiesz o programowaniu i projektowaniu baz danych . Wygląda na to, że powinieneś trochę poczytać. Koncepcyjnie jednak twój projekt jest dość prosty. Twój opis identyfikuje tylko dwa podmioty:
- Instrument finansowy; i
- Cytuj.
Musisz więc następnie zidentyfikować atrybuty.
Instrument finansowy:
- Kod bezpieczeństwa;
- Rynek;
- itd.
Cytat:
- sygnatura czasowa;
- Instrument finansowy;
- Cena oferty; i
- Zadaj cenę.
Odniesienie do instrumentu finansowego to tak zwany klucz obcy . Każda tabela wymaga również klucza podstawowego , prawdopodobnie tylko pole auto-inkrementacji.
Koncepcyjnie dość proste.
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'
Jeśli Twój zbiór danych jest wystarczająco duży, możesz chcieć dołączyć (oferta + zapytanie) / 2 w tabeli, aby nie trzeba było obliczać w locie.
Ok, więc to jest znormalizowany widok. Po tym może być konieczne rozpoczęcie optymalizacji wydajności. Rozważ to pytanie dotyczące przechowywania miliardów wierszy w MySQL . Partycjonowanie to funkcja MySQL 5.1+ (dość nowa).
Ale inne pytanie, które należy sobie zadać, brzmi:czy musisz przechowywać wszystkie te dane? Powodem, dla którego o to pytam, jest to, że kiedyś pracowałem w pośrednictwie internetowym i przechowywaliśmy wszystkie transakcje tylko przez bardzo ograniczone okno, a transakcje byłyby mniejszym zestawem danych niż kwotowania, których wydajesz się chcieć.
Przechowywanie miliardów wierszy danych to poważny problem i naprawdę potrzebujesz poważnej pomocy w rozwiązaniu.
