Jointure tables
Fermé
chaldeen
Messages postés
12
Date d'inscription
mardi 13 avril 2021
Statut
Membre
Dernière intervention
20 février 2023
-
Modifié le 13 avril 2021 à 16:17
yg_be Messages postés 22616 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 26 mars 2024 - 1 mai 2021 à 21:02
yg_be Messages postés 22616 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 26 mars 2024 - 1 mai 2021 à 21:02
A voir également:
- Jointure tables
- Tables des matieres - Guide
- Tables ascii - Guide
- Jointure php - Forum PHP
- Sql soustraction entre 2 tables - Forum Webmastering
- Comparer deux tables sql ✓ - Forum Programmation
2 réponses
yg_be
Messages postés
22616
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
26 mars 2024
1 461
13 avril 2021 à 20:17
13 avril 2021 à 20:17
bonjour,
essaie de donner plus de texte, et moins d'images.
quand tu écris "1ère image", je suppose qu'il s'agit de la deuxième, la première étant la structure de tes tables.
avant d'importer les données, concentrons-nous sur la conception des tables.
"comptage", dans la table "mesure", c'est le total quotidien?
c'est quoi les champs "mesure" et valeur" dans la table decoupage_heure?
c'est quoi la table decoupage_type? d'où vient ce "type"?
voyant tes données, je pense qu'il faut une table station,
et une table mesure, avec 4 champs, id_station, date, heure, et mesure
essaie de donner plus de texte, et moins d'images.
quand tu écris "1ère image", je suppose qu'il s'agit de la deuxième, la première étant la structure de tes tables.
avant d'importer les données, concentrons-nous sur la conception des tables.
"comptage", dans la table "mesure", c'est le total quotidien?
c'est quoi les champs "mesure" et valeur" dans la table decoupage_heure?
c'est quoi la table decoupage_type? d'où vient ce "type"?
voyant tes données, je pense qu'il faut une table station,
et une table mesure, avec 4 champs, id_station, date, heure, et mesure
mamiemando
Messages postés
33025
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
28 mars 2024
7 736
Modifié le 14 avril 2021 à 13:53
Modifié le 14 avril 2021 à 13:53
Bonjour,
Personnellement ça me paraît être un schéma de base de donnée bien compliqué pour pas grand chose, et surtout qui risque d'être coûteux à exploiter, car il va t'amener à faire plein de jointures. Or les jointures, ça passe mal à l'échelle : une jointure entre deux tables de tailles m et n revient à faire leur produit cartésien en ne conservant que les records qui se rejoignent, ce qui se fait en O(m.n). Si m et n sont grands, ça ne pas passera donc pas à l'échelle.
Dans ton cas, j'aurais adopté un schéma plus simple : j'aurais mis les champs associés à
Si tu as un gros volume de mesures (ce qui finit par arriver inévitablement si on attend assez longtemps), il sera alors plus simple de partitionner ta table mesure (e.g. par mois ou par année). Ainsi en fonction de la requête, tu pourras chercher les mesures dans les tables qui couvrent un intervalle de temps pertinent.
Bonne chance
Personnellement ça me paraît être un schéma de base de donnée bien compliqué pour pas grand chose, et surtout qui risque d'être coûteux à exploiter, car il va t'amener à faire plein de jointures. Or les jointures, ça passe mal à l'échelle : une jointure entre deux tables de tailles m et n revient à faire leur produit cartésien en ne conservant que les records qui se rejoignent, ce qui se fait en O(m.n). Si m et n sont grands, ça ne pas passera donc pas à l'échelle.
Dans ton cas, j'aurais adopté un schéma plus simple : j'aurais mis les champs associés à
decoupage_heureet
decoupage_mesuredirectement dans la table
mesure, car si ma compréhension est correcte, une mesure impliquera toujours (ou presque toujours) un
decoupage_heureet un
decoupage_type. Si ce que je dis est correct, l'espace "perdu" pour les cas où ces champs ne seraient pas exploités serait donc minime.
Si tu as un gros volume de mesures (ce qui finit par arriver inévitablement si on attend assez longtemps), il sera alors plus simple de partitionner ta table mesure (e.g. par mois ou par année). Ainsi en fonction de la requête, tu pourras chercher les mesures dans les tables qui couvrent un intervalle de temps pertinent.
Bonne chance
chaldeen
Messages postés
12
Date d'inscription
mardi 13 avril 2021
Statut
Membre
Dernière intervention
20 février 2023
16 avril 2021 à 11:01
16 avril 2021 à 11:01
Bonjour et merci pour votre réponse,
Malheureusement, je ne possède que des données quotidiennes de 2014 à 2020, et ce n'est que depuis 2020 que je possède une granularité horaire, idem pour les types, ce qui laisserait vraiment beaucoup de valeurs vides.
Dans votre explication, comment auriez-vous vu les choses ? Vous auriez par exemple mis 24 attributs correspondant aux heures dans la table Mesure ? Ou alors mis une ligne (enregistrement) par mesure (station/date) et par heure, ce qui fait qu'il y aurait eu 24 enregistrements pour les dates possédant la granularité horaire et seulement 1 pour les date ne possédant que le total quotidien ?
Merci à vous
Malheureusement, je ne possède que des données quotidiennes de 2014 à 2020, et ce n'est que depuis 2020 que je possède une granularité horaire, idem pour les types, ce qui laisserait vraiment beaucoup de valeurs vides.
Dans votre explication, comment auriez-vous vu les choses ? Vous auriez par exemple mis 24 attributs correspondant aux heures dans la table Mesure ? Ou alors mis une ligne (enregistrement) par mesure (station/date) et par heure, ce qui fait qu'il y aurait eu 24 enregistrements pour les dates possédant la granularité horaire et seulement 1 pour les date ne possédant que le total quotidien ?
Merci à vous
mamiemando
Messages postés
33025
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
28 mars 2024
7 736
>
chaldeen
Messages postés
12
Date d'inscription
mardi 13 avril 2021
Statut
Membre
Dernière intervention
20 février 2023
21 avril 2021 à 15:44
21 avril 2021 à 15:44
Je pensais que la plupart de tes mesures avait une granularité horaire, donc je pensais que le problème de place perdue n'était pas très important.
Vu que les nature des mesures semble dépendre de l'année, si tu fais une partition par année (cf ma discussion sur le passage à l'échelle) et avoir un schéma de table différent pour les années pré-2020 et post-2020. Ensuite, à l'aide d'une vue et/ou avec une procédure stockée, tu peux interroger les bons champs des bonnes partitions et réunir les résultats extraits de chaque partition. Après les partitions ne deviennent intéressantes que si tu manipules de gros volumes de données. Bref c'est peut être overkill dans ton cas...
Vu que les nature des mesures semble dépendre de l'année, si tu fais une partition par année (cf ma discussion sur le passage à l'échelle) et avoir un schéma de table différent pour les années pré-2020 et post-2020. Ensuite, à l'aide d'une vue et/ou avec une procédure stockée, tu peux interroger les bons champs des bonnes partitions et réunir les résultats extraits de chaque partition. Après les partitions ne deviennent intéressantes que si tu manipules de gros volumes de données. Bref c'est peut être overkill dans ton cas...
yg_be
Messages postés
22616
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
26 mars 2024
1 461
>
chaldeen
Messages postés
12
Date d'inscription
mardi 13 avril 2021
Statut
Membre
Dernière intervention
20 février 2023
1 mai 2021 à 21:02
1 mai 2021 à 21:02
peux-tu donner suite, ou marquer comme résolu?
13 avril 2021 à 20:26
1) en python, tu "analyses" les données, et tu fais l'insertion des enregistrements avec la bonne heure
2) tu importes les données brutes dans une table intermédiaire à 26 champs, tu exécutes une requête SQL qui importe les données de la table intermédiaire dans la table mesure, et tu vides la table intermédiaire.
16 avril 2021 à 11:34
'Comptage' représente effectivement le total quotidien, qui était directement disponible dans le fichier csv jusqu'à 2019, et que j'ai du calculer manuellement dans le fichier à partir de 2020.
Dans la table 'découpage_heure', mesure représente l'id_mesure (correspond à chaque station/jour) et valeur au nombre de voitures par heure (cf 2ème image, sous la structure des tables).
Idem pour la table découpage_type, même structure, mais à la place des heures, chaque colonne du fichier csv représente un type de véhicule (électrique, location, etc). Le fichier csv a la même organisation de celui des heures (2ème image).
Merci beaucoup !
16 avril 2021 à 13:14
donc, une table station,
et une table mesure, avec 5 champs: id_station, date, heure, mesure et type
en effet, dans la table mesure, 24 enregistrements pour les dates possédant la granularité horaire et seulement 1 pour les date ne possédant que le total quotidien (tout cela sans tenir compte du type, à propos duquel tu donnes peu d'information factuelle.
tout le reste tu le calculeras avec des requêtes.
16 avril 2021 à 13:48
Merci en tout cas