web-dev-qa-db-fra.com

Schéma de base de données pour organiser des données historiques sur actions

Je crée un schéma de base de données pour stocker des données historiques sur actions. J'ai actuellement un schéma comme indiqué ci-dessous.

Mes exigences sont de stocker des "données de barre" (date, ouverte, haut, faible, volume proche) pour plusieurs symboles de stock. Chaque symbole peut également avoir plusieurs délais (par exemple, les barres hebdomadaires Google et les barres quotidiennes Google).

Mon schéma actuel met la majeure partie des données dans la table OHLCV. Je suis loin d'un expert de base de données et je suis curieux si cela est trop naïf. L'entrée constructive est la bienvenue.

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);

Cela signifie que mes requêtes vont actuellement quelque chose comme: trouvez la TimeFrameID pour un symbole/délai donné, puis effectuez une sélection sur la table OHLCV dans laquelle le calendrier correspond à la hauteur.

sqlsqliteschemastocks
31
nall

Eh bien, du côté positif, vous avez le bon sens de demander une entrée en premier. Cela vous met en avant 90% des personnes inconnues avec la conception de la base de données.

  • Il n'y a pas de relations clés étrangères claires. Je suppose que timeframeID concerne symbolID?
  • On ne sait pas comment vous seriez capable de trouver quoi que ce soit de cette façon. La lecture sur des clés étrangères susmentionnées devrait améliorer considérablement votre compréhension avec peu d'effort.
  • Vous stockez les données du calendrier comme TEXT. D'une performance ainsi que d'une perspective de convivialité, c'est un non-non.
  • Votre schéma actuel ne peut pas accommoder les scissions de stock, ce qui se produira éventuellement. Il est préférable d'ajouter une autre couche d'indirection entre la table de données de prix et le symbole
  • open, high, low, close Les prix sont mieux stockés comme des types décimaux ou de devises, ou de préférence, en tant que champ INTEGER Avec un champ distinct INTEGER stockage du diviseur, comme la plus petite fraction de prix (cents, huit dollars, etc.) autorisées varie par échange.
  • Puisque vous soutenez plusieurs échanges, vous devez prendre en charge plusieurs devises.

Je m'excuse si tout cela ne semble pas trop "constructif", surtout que je suis trop somnolent pour suggérer une alternative plus utilisable. J'espère que ce qui précède est suffisant pour vous mettre sur votre chemin.

27
Michiel Buddingh

Nous avons essayé de trouver une structure de base de données appropriée pour stocker une grande quantité de données pendant une longue période. La solution ci-dessous est le résultat de plus de 6 ans d'expérience. Cela fonctionne maintenant parfaitement pour notre analyse quantitative.

Nous avons pu stocker des centaines de gigaoctets d'intraday et de données quotidiennes à l'aide de ce schéma dans 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

Tous les instruments de trading sont stockés dans une seule table. Nous avons également un index en cluster sur le symbole, la date et les colonnes temporelles.

Pour les données quotidiennes, nous avons une table séparée et n'utilisons pas la colonne TIME. Volume DataType est également Bigint au lieu de INT.

La performance? Nous pouvons obtenir des données hors du serveur en matière de millisecondes. N'oubliez pas que la taille de la base de données est de près de 1 téraoctet.

Nous avons acheté toutes nos données historiques sur le marché du site Web de Kibot: http://www.kibot.com/

34
boe100

Je ne suis pas sûr de quelle valeur est ajoutée par Timeframe - Cela semble être une complication inutile, mais cela pourrait être quelque chose que je ne comprends pas de comprendre ;-) Un calendrier a-t-il plus d'une période de travail? Sinon, alors je suggérerais qu'ils soient fusionnés.

Je noterais également que les tictions boursiers changent de temps en temps pour un certain nombre de raisons. Ce n'est pas un événement fréquent, mais cela arrive. Si vous envisagez de travailler avec vos données comme série chronométrée, vous devez être conscient du problème afin que vous puissiez le gérer quand il s'agit, sinon auparavant. Si vous ne suivez pas les stocks (vous pouvez travailler sur une application à terme, disons) alors ce conseil peut être pris avec la quantité de sel appropriée.

À nouveau principalement pertinents pour les stocks, les scissions ont été mentionnées ailleurs et vous voudrez peut-être envisager des dividendes - un prix d'actions baissera généralement par le montant du dividende (ou plus précisément la valeur actuelle) de la date de dividende, qui peut être mal interprétée si Vous ne savez pas qu'un flux de trésorerie futusif confirmé était la raison. Les problèmes de droits peuvent aussi être amusants.

Si vous envisagez de rechercher des séries de données pour un symbole particulier, je suggère de regarder sur le type de performance que vous allez obtenir. À tout le moins, assurez-vous d'avoir un indice approprié en place.

4
Mike Woodhouse