Discussion :

[nrpfc]

Bonjour,

voilà je suis actuellement en stage en entreprise et j'ai pour mission d’implémenter un serveur Windows 2003 avec une base de données MySQL , jusque la tout va bien
la base de données je dois la développer à partir de fichier *.csv, je joins un extrait de fichier, je l'ai mis en format ods car le csv n'est pas supporté ici (il y a au maximun 87 600 lignes sur un fichier, une mesure toute les 6 minutes multiplié par 12 stations)

J'ai quelques impératifs :
Les données devront pouvoir être remonté tout les mois à partir de ces fichiers.
Apparitions des heures UTC dans une colonne spécifique.
Faire apparaître les lignes manquantes dans les relevés, il manque des lignes pour des raisons de panne ou de maintenance.

Voilà ce que j'ai fait :
j'ai remonté les données *.csv dans 6 tables distinct (une par année).
Création d'une table Stations
Création d'une table Capteurs
Création de 6 tables Calendrier (une par année)

La table Stations comporte 3 colonnes : id_station (clef primaire), Departement et localisation.

La table Capteurs comporte 16 colonnes : id_capteur (clef primaire) et les 15 autres qui servent à décrire le capteur.

Les Tables Calendrier comportent 5 colonnes : id_calendrier (clef primaire), id_station, date_heure_locale, date_heure_UTC et commentaires.

Enfin les données que j'ai remonté sont dans une table ayant 85 colonnes : id_station, date_heure_locale et les 83 colonnes qui restent vont de 0 à 82 pour chaque capteurs.
La clef primaire est faite de 2 colonnes (id_station et date_heure_locale).

Au début je pensais fusionner les tables calendrier avec les tables données des années correspondantes, mais je me suis dis que ça risquer de rendre plus compliqué la remonté des données par la suite.
Du coup j'ai pensé aux clefs étrangères, je voudrais prendre pour clef étrangère les 2 colonnes « id_station et date_heure_locale » sur les tables calendrier et données.
La question qu'on m'a posé est la suivante : « sera-t-il possible d'extraire une table ou seront présente les colonnes date_heure_locale et date_heure_UTC et est ce que les lignes manquantes sur la table données seront visible ?
Actuellement je travail sur la requête capable de m'afficher tout ça à partir des 2 tables en question sur une période donnée.

Je suis novice sur MySQL, il y a encore 3 semaines de ça je ne connaissais rien aux bases de données et encore moins a MySQL.
Merci de me donner votre avis sur ce que j'ai fait et de me dire ce que je peux améliorer, voir changer pour améliorer ma base.

nrpfc

[ericd69]

salut,

tes tables calendrier sont les tables de données? car ton explication se contredit un peu là dessus?

[skuatamad]

Je ne reviens pas sur l'ensemble de la modélisation.

Cependant, la table calendrier n'a pas à contenir d'information sur les serveurs.
La table calendrier n'est pas alimentée par les batch remontant les infos des capteurs, elle est créée une fois pour toute (à la maintenance près) et contient directement 10, 20 ou 50 ans, ainsi que des infos sur les mois, années, semaines, jours fériés ou autres en fonction des besoins.
Il n'y a pas d'intérêt à avoir une table calendrier par année.

Concernant le choix du SGBD, comme tu es en début de projet, et que le projet semble plus particulièrement orienté reporting développé manuellement en SQL, je pense que le choix de mysql n'est pas adapté, postgresql sera nettement meilleur offrant de nombreuses fonctionnalités SQL de requêtage que n'offre pas mysql (ex et pas des moindres les fonctions de fenêtrage)

Pour ce genre de projet, il sera également intéressant de regarder du côté du partitionnement de table (peut être pas tout de suite mais très probablement d'ici quelques années).
Postgresql semble également être plus abouti dans ce domaine que mysql.

[CinePhil]

Je ne reviens pas sur l'ensemble de la modélisation.

Tu devrais !
Tu n'es même pas choqué par ça ?

et les 83 colonnes qui restent vont de 0 à 82 pour chaque capteurs

je pense que le choix de mysql n'est pas adapté, postgresql sera nettement meilleur

implémenter un serveur Windows 2003 avec une base de données

Puisqu'on est dans le monde Windows, on peut aussi suggérer Microsoft SQL Server Express. Voir si sa limitation en taille de BDD est acceptable pour ce projet.

Mais avant toute chose, j'inciterais fortement nrpfc à proposer et discuter de son modèle de données dans le forum Schéma.

[nrpfc]

Merci pour vos réponses,

Je n'ai malheureusement pas le choix quant a la plateforme, c'est MySQL^^

la table données est faite à partir des fichiers *.csv, les données arrivent sous cette forme, soit id_station(12), date_heure_locale(toute les 6mn) et de 0 à 82 (les 83 capteurs)
comme je vous l'ai dit je fait mon possible pour faire quelques choses de fonctionnel avec mes maigres competences dans le domaine ^^

si j'ai créée la table calendrier c'etait dans le but d'avoir un point de comparaison avec la table données et pouvoir connaitre les date_heure manquantes ...
j'en ai creer une par annee pour pouvoir la lier plus facilement avec une clef etrangere a la table données.

pour info une table calendrier contient 1 051 200 lignes, mes tables données en contiennent entre 825 000 et 975 000, je vous laisse imaginer les trous ^^

je vais de ce pas sur le forum schéma ^^
merci pour votre aide

[skuatamad]

Tu devrais !
Tu n'es même pas choqué par ça ?

Je ne dis pas que c'est bon, je dis que je ne l'aborde pas, car pas le temps ou pas la motivation (je n'ai pas regardé le fichier)
Après 80 colonnes ça ne veut pas forcément dire mauvaise modélisation surtout en décisionnel, il y a le forum modélisation pour çà.

Pourquoi pas une version express effectivement, mais s'il y a déjà quelques années de données à intégrées, je pense que le 1Go de RAM dispo sera vite dépassé.
Par contre c'est vrai que postgresql est plus généralement utlisé sur linux.

[ericd69]

les 80 colonnes, il a pas forcément le choix, s'il a 80 capteurs, après faut voir s'il y a besoin d'une simultanéité de mesure ou pas...

par contre ce qui me gène c'est plus l'histoire des table calendrier/données????
on sait pas si c'est l'un ou l'autre...

pour les partitions... si la masse de données est importante déjà ça vaut le coup... mais dans ce cas il vaut mieux s'y mettre dés le départ vu que ça joue sur le besoin d'index et si tu dois scinder physiquement ou non tes donnée...
en plus tu dois vérifier que la version de mysql utilisée le permet...

pour les dates en local/utc, tu as des conversions, pas besoin de stocker les 2...

bref il serait peut-être bien de remettre un peut les choses à plat avant de se lancer