Je veux enregistrer et afficher des prix historiques de 2500 cryptocurrences. Quelle est la meilleure stratégie pour enregistrer toutes ces données sur ma base de données? Je pense que ce n'est pas une bonne idée de créer 2500 tables avec une ligne pour chaque prix ...
Base de données: Postgres
Merci beaucoup
3 Réponses :
MongoDB pourrait être une bonne option. Créer pour chaque monnaie une collection. Veillez à ne pas charger à de grandes collections à la fois, créez plutôt une collection agrégée.
Merci beaucoup. J'ai oublié de dire que j'utilise Postgres ...
C'est une question très large, mais probablement un schéma d'étoiles vous aiderait à la configurer de manière flexible et évolutive.
Je peux envisager cela comme une configuration très simple avec une table de fait contenant les données historiques sur les prix par un horodatage et quelques tables de dimensions détenant des informations sur les pièces (c'est-à-dire des taux de change, des marchands) etc.
Ceci est un guide simple sur STAR SCHEMA
Dans mes humbles questions d'opinion comme celle-ci ne semble pas "trop large".
Vous pouvez toujours créer une table et l'avoir partitionné par année, éventuellement Code crypto si vous avez beaucoup de points de prix.
Je suis personnellement un fan de modèles de données dénormalisés, mais si vous envisagez de stocker le code crypto dans une table séparée et que les points de prix d'un autre, il peut y avoir un petit avantage en termes de temps de requête - indexer la table des points de prix basée sur la table. sur un entier (crypto_id) peut entraîner des requêtes plus rapides.
Les attributs d'un prix historique varient d'une cryptocurrence à la cryptocurrence? C'est-à-dire qu'un prix historique de cryptocurrence a-t-il des attributs différents que les prix historiques de Cryptocurrenceb? Ou, les prix historiques ont-ils tous les mêmes attributs indépendamment de la cryptocurrence? S'ils varient, par combien?