Discussion :

[newproger]

Bonjour,

Je dois stocker des informations financières (prix d'une centaine d'actions) sur une années.

- J'ai un flux me fournissant les Ticks (Datetime, Action, Prix, Quantité)
- des indicateurs devront etre calculé sur différents timeframe (bar 1 min, 10 min, ...)

Je me pose donc la question de l'interet de
- stocker les ticks pour recalculer a la volé les Bar OHLC (directement en SQL?) en fonction du besoin ?
- stocker les timeframe qui m'interesse aukourd'hui (une dizaine) sachant que les besoins d'oujourd'hui ne sont pas ceux de demain ?
- stocker les informations en bar secondes (voir minutes) sachant que pour le moment je n'ai pas de demande sous la minute et de calculer les timeframe a partir de ces bar seconde voir minute (Toujours en SQL?) ?

Ma seconde question concerne les bar 'vide', par exemple
- 10h43 du volume
- 10h44 pas de volume (donc absente en base)
- 10h45 du volume

Si je dois appliquer un algo utilisant 3 bar simultané celle de 10h44 n'apparaitra pas, du coup pas possible de faire cela en SQL.
Dans ce cas pensez vous qu'il faudait générer des bar ou Open-High-Low-Close valent le close de la barre précédente avec un volume de 0 en base ?

merci de votre aide

[SQLpro]

Il vous faut absolument modéliser de façon conceptuelle. Il vous sautera aux yeux qu'il est impératif d'avoir une entité de temps avec des points à la granularité voulue, par exemple, la minute.

A +

[newproger]

Merci SQL Pro,

J'ai essayé de voir ce que cela pouvait donner, en effet avec des bar minutes je suis en train de faire une requêtes me permettant de récupérer directement de la base le timeframe désiré.
Je ne sais pas si SQL Server est le mieux adapter a ce genre de problématique, je vois souvent dans la finance revenir les noms de KDB+ ou de base nosql colonne pour le stockage.
Pour le moment il m'est demandé de le faire en SQL Server 2012-2014

La base que je récupère est constitué de N table, ou chacune contient un timeframe différents ...

[StringBuilder]

Je vois pas trop pourquoi SQL Server ne serait pas adapté.

Sur-dimensionné peut-être ? Mais sorti de ça, rien ne me semble contre-indiqué.

Sinon, pour une question de "rétro-compatibilité" (si les besoins évoluent), je stockerais avant tout les "raw data", soit dans la même schéma/base, soit dans une nouvelle, afin de conserver l'historique des données brutes (chaque tick).

Niveau volumétrie, vérifier que c'et pas trop gros cependant (mais j'ai cru comprendre que c'était quelques centaines de lignes avec peu de données par seconde, ça ne devrait pas poser de problème).

Ensuite, par tâche planifiée, consolider les données avec la granularité voulue, dans d'autres tables (ou autre schéma/base).

Comme ça, si par exemple demain il faut retrouver la valeur minimum (brute, à la seconde près) et non la valeur moyenne de la minute la plus basse, tu as la donnée sous la main.