Comment Structurer ma table pour ce type de requête

Bonjour

J'ai l intention de créer une table de cours de bourse avec les prix à l ouverture, la fermeture, le plus haut et le plus bas de chaque heure.

Avec une requête je souhaite trouver le plus haut sur 24h00 'glissantes', c est à dire du 01.01.2020 13h00 au 02.01.2020 13h59, du 01.01.2020 14h00 au 02.01.2020 14h59... je crois que vous avez compris l idée.

Je me demande donc s il est plus facile d'utiliser un champ DateTime ou un champ Date et un Champ Time.

Si je me pose cette question c est qu j ai vu que l on pouvait appliquer le parametre INTERVAL 1 DAY dans une requete mais dans ce cas la sélection ne se ferait elle pas de 13h00 à 13h00 par exemple. Peut etre qu un champ DateTime avec interval 1339 ferait mon affaire.

Ma table va contenir beaucoup de données donc j aimerai, outre les index, la construire de façon à ce qu elle soit aussi optimisée.

Dernier point : est il plus rapide de faire 2 requêtes pour le plus_haut et le plus_bas ou une seule accélère le traitement (je ne connais pas grand chose aux requêtes imbriquées)

merci pour vos conseils

Bonjour,

Une seule colonne (dans une base de données, il n'y a pas de "champ") permet d'utiliser l'opérateur between, plus simple dans votre cas d'horizon glissant.

Une seule requête permet de récupérer le min et le max pour un même critère de regroupement, ce sera plus performant que deux accès.

Citation:

---

J'ai l intention de créer une table de cours de bourse avec les prix à l ouverture, la fermeture, le plus haut et le plus bas de chaque heure.

---

Ce qu'on entend généralement par "prix à l ouverture" et "prix à la fermeture" sont les cours à l'ouverture de la séance de bourse le matin et le cours à la clôture de la cotation le soir. Est-ce là aussi le cas ou bien souhaitez vous le cours en début et en fin de chaque heure ?

merci pour vos réponses.

@CinePhil Chaque enregistrement de la base de données correspondra effectivement au cours d'ouverture et de clôture non pas de bougies quotidiennes mais de bougies en 1 minutes.
La stratégie que je souhaite évaluer est développée sur des bougies quotidienne mais donne assez peux de signaux. Les bougies quotidiennes lors de cotations 24h/24h comme les cfd (ce qui m intéresse) sont basées sur 00h00. De ce fait, afin de tester sur un panel plus large j envisage de reconstituer des bougies quotidiennes pour 00h, 01h, 02h... 23h00

OK,

1) Vous chargerez votre table à partir d'un flux externe qui ne donnera que ces propriétés ?

2) Vous analyserez plusieurs valeurs cotées, j'imagine ?


Si oui aux deux question, alors voilà ce qu'il vous faut a minima :
1) Une table des valeurs
te_valeur_val (val_id, val_isin, val_nom...)

Exemple :
1, 'NL0000235190', 'Airbus'

2) Une table des cotations
te_cotations_cot (cot_id_valeur, cot_date_heure, cot_ouverture, cot_fermeture, cot_plus_haut, cot_plus_bas)

Exemple :
1, '2020-03-09 09:00', 87.43, 90.53, 90.68, 88,22


Je vous laisse ensuite essayer de construire votre requête pour avoir le plus haut et le plus bas sur 24h.

Merci pour ces conseils.
Pour l instant je ne traite qu un produit à la fois donc je n ai que la table relative aux cotations.

Ce n'est pas une raison : la table des produits ne doit contenir que les attributs du produit indépendamment de la date de cotation, sinon il y a redondance d'information et donc encombrement inutile de la BDD et risque d'erreurs.

Le MCD étant
[PRODUIT] 1,n --- coter --- 1,1 [COTATION]

il y a obligatoirement deux tables (cardinalité maxi n coté produit oblige) ;)

Merci mais je me suis peut être mal fait comprendre ou je n ai pas compris mais dans mon cas il n y a pas de redondance puisque j importe le fichier des cotations relatives à un seul et unique produit donc je n ai pas besoin de la première table qui référence tous les produits.
Si j utilise une bdd c est que le fichier est trop important pour faire comme je fais avec un fichier plus léger, c est à dire tout mettre dans une liste d objets. C est simplement pour avoir une structure et me faciliter la vie à faire des requêtes au lieu de boucles.