Schemat bazy danych do organizowania historycznych danych magazynowych

Tworzę schemat bazy danych do przechowywania historycznych danych giełdowych. Obecnie mam schemat, jak pokazano poniżej.

Moje wymagania to Przechowywanie " bar data "(data, open, high, low, close volume) dla wielu symboli akcji. Każdy symbol może również mieć wiele ram czasowych (np. Google Weekly bars i Google Daily bars).

Mój aktualny schemat umieszcza większość danych jest w tabeli OHLCV. Jestem daleki od eksperta od baz danych i jestem ciekaw, czy to zbyt naiwne. Konstruktywny wkład jest bardzo mile widziany.

CREATE TABLE Exchange (exchange TEXT UNIQUE NOT NULL);

CREATE TABLE Symbol (symbol TEXT UNIQUE NOT NULL, exchangeID INTEGER NOT NULL);

CREATE TABLE Timeframe (timeframe TEXT NOT NULL, symbolID INTEGER NOT NULL);

CREATE TABLE OHLCV (date TEXT NOT NULL CHECK (date LIKE '____-__-__ __:__:__'),
    open REAL NOT NULL,
    high REAL NOT NULL,
    low REAL NOT NULL,
    close REAL NOT NULL,
    volume INTEGER NOT NULL,
    timeframeID INTEGER NOT NULL);

Oznacza to, że moje zapytania są obecnie podobne: Znajdź timeframeID dla danego symbolu/timeframeid, a następnie wykonaj select w tabeli OHLCV, gdzie pasuje timeframeID.

Author: nall, 2009-10-06
Source

3 answers

Cóż, z drugiej strony, masz rozsądek, by najpierw poprosić o wejście. To stawia Cię przed 90% osób nieznających projektowania baz danych.

  • nie ma wyraźnych relacji klucza obcego. Rozumiem, że timeframeID odnosi się do symbolID?
  • nie jest jasne, jak będziesz w stanie znaleźć cokolwiek w ten sposób. Czytanie wyżej wymienionych kluczy obcych powinno znacznie poprawić zrozumienie przy niewielkim wysiłku.
  • przechowujesz dane czasowe jako TEXT. Od a wydajność, a także perspektywa użyteczności, To Nie-Nie.
  • Twój obecny system nie może pomieścić podziału akcji, co w końcu się stanie. Lepiej dodać jeszcze jedną warstwę indrection pomiędzy tabelą cen a symbolem
  • open, high, low, close ceny są lepiej przechowywane jako typy dziesiętne lub walutowe, lub, najlepiej, jako pole INTEGER z oddzielnym polem INTEGER przechowującym dzielnik, jako najmniejszy ułamek ceny (centy, ósemki dolara itp.) dopuszczalne różnice w zależności od wymiany.
  • ponieważ obsługujesz wiele giełd, powinieneś obsługiwać wiele walut.

Przepraszam, jeśli to wszystko nie wydaje się zbyt "konstruktywne" , zwłaszcza, że jestem teraz zbyt senny, aby zaproponować bardziej użyteczną alternatywę. Mam nadzieję, że powyższe wystarczy, aby ustawić cię w drodze.

 29
Author: Michiel Buddingh,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-07-08 13:51:38

Staraliśmy się znaleźć odpowiednią strukturę bazy danych do przechowywania dużej ilości danych przez długi czas. Poniższe rozwiązanie jest wynikiem ponad 6-letniego doświadczenia. Teraz działa bez zarzutu dla naszej analizy ilościowej.

Udało nam się zapisać setki gigabajtów danych intraday i daily używając tego schematu w SQL Server: 

 Symbol -  char 6
 Date -  date
 Time -  time
 Open -  decimal 18, 4
 High -  decimal 18, 4
 Low -  decimal 18, 4
 Close -  decimal 18, 4
 Volume -  int

Wszystkie instrumenty handlowe są przechowywane w jednej tabeli. Mamy również klastrowy indeks na symbol, datę i godzinę kolumny.

Dla danych dziennych mamy oddzielną tabelę i nie używamy kolumny czasu. Typ danych woluminów to również bigint zamiast int.

Przedstawienie? Możemy pobrać dane z serwera w ciągu milisekund. Pamiętaj, że rozmiar bazy danych wynosi prawie 1 terabajt. Wszystkie nasze historyczne dane rynkowe zakupiliśmy na stronie Kibot: http://www.kibot.com/
 39
Author: boe100,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-01-14 08:30:54

Nie jestem pewien, jaką wartość dodaje Timeframe - wydaje się to niepotrzebną komplikacją, ale to może być coś, czego nie rozumiem ; -) czy ramy czasowe mogą mieć więcej niż jeden OHLCV? Jeśli nie, sugerowałbym ich połączenie.

Chciałbym również zauważyć, że znaczniki akcji zmieniają się od czasu do czasu z wielu powodów. Nie jest to częste wydarzenie, ale zdarza się. Jeśli myślisz o pracy z danymi jako szeregami czasowymi, powinieneś być świadomy problemu, aby móc sobie z nim poradzić kiedy nadejdzie, jeśli nie wcześniej. Jeśli nie śledzisz akcji (możesz pracować nad aplikacją futures, powiedzmy), możesz skorzystać z tej porady z odpowiednią ilością soli.

Ponownie dotyczy głównie akcji, splity zostały wymienione gdzie indziej i możesz rozważyć dywidendy-cena akcji zazwyczaj spadnie o kwotę dywidendy (a dokładniej jej aktualną wartość) w dniu bez dywidendy, co może zostać błędnie zinterpretowane, jeśli nie znasz potwierdzonej przyszłej gotówki przepływ był powodem. Kwestie praw też mogą być zabawne.

Jeśli planujesz przyjrzeć się serii danych dla konkretnego symbolu, sugeruję przyjrzeć się, jaki rodzaj wydajności otrzymasz. Przynajmniej upewnij się, że masz odpowiedni indeks.

 4
Author: Mike Woodhouse,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-10-06 08:15:18