Champs créés par Data2SQL dans les tables de la BDD

[Météo Villarzel]

oui, c'est effectivement une solution, par contre

Je pense qu'il faudrais également effacer les enregistrements de la table MiniMaxidata sur la même période que la table data pour que le soft de Jean mette à jour cette table

la table maximini ne vas pas se mettre à jours si tu n'effaces pas aussi les valeurs dans la table data.

A+

[PascalWMR]

oui oui Pierre-André c'est ce que j'ai préconisé

Effacer les enregistrements dans les deux tables et sur la même période

A+

[jturlier]

Je pense qu'il faudrait également effacer les enregistrements de la table MiniMaxidata sur la même période que la table data pour que le soft de Jean mette à jour cette table

A la demande de PascalWMR pour que je jette un coup d’œil à ce sujet,

Je réitère ce que j'ai dit sur le forum de GraphWeather : je ne fais ni ne ferai plus aucune modification dans DATA2SQL, il existe maintenant d'autres programmes qui le remplacent. La dll qui traitait les fonctions de la base de données a été très largement modifiée ce qui empêche toute reprise de ce programme -pourquoi faire du vieux quand on a du neuf-.
De plus il existe de nombreuses erreurs dans la table minimaxi qui ont été corrigées dans les nouvelles versions (je l'espère, Pierre-André, Pascal et Pidou m'ont assez pourri la vie avec ça ).

Par contre, s'il y a des forts en math, j'aurais bien inclus ces champs pour les autres stations si j'avais eu la possibilité de les calculer dans la table détail, mais les algorithmes sont inbitables (pour moi) et mes derniers cours de math remontent à 64, et le peu que j'ai pratiqué ensuite était très orienté statistiques.
Donc si quelqu'un se sent en forme et a l'esprit clair pour me fournir ces algorithmes (assimilables facilement par un nul), je ferai même la modification dans la table minimaxi, mais n'oubliez pas qu'il n’y a pas que la VP2 dans le monde des stations et que le but de ces programmes est d'avoir une base de données universelle !
Ce type d'opération qui consisterait à rajouter des colonnes supplémentaires nécessiterai une recompilation de tous les autres programmes et il faudrait prévoir dedans l'ajout de colonnes dans la table minimaxi en évitant naturellement le rechargement complet des tables.

J'espère avoir clarifié la situation

Une petite précision : Puisque ces programmes travaillent tous avec des bases de données, vous devez bien vous douter, qu'avec une "simple" requête, on peut facilement transférer les données d'une table dans une autre, le plus ch...t c'est d'indiquer les colonnes dans le select (il y en a 75 dans la nouvelle table et plus de 120 dans minimaxi !!!! Donc si quelqu'un se sent une âme d'expert SQL, il n'y a rien de compliqué, il faut juste de la rigueur et une bonne vue pour ne pas se croiser les yeux.
Autre petite précision : il est toujours plus "rapide" de recharger une table locale plutôt qu'une table distante et il est ensuite très rapide de faire une sauvegarde locale puis de la restaurer sur le serveur distant à partir des outils locaux MySQL wokrbench par exemple, je ne parle pas de phpmysql étant donné que je ne l'ai jamais utilisé et que les outils que je possède me conviennent parfaitement .

[PascalWMR]

Bonjour

Petite question

A quoi correspond le champs UV_Dose_jour et quelle est sont unité de mesure?
Comment peut-on employer cette données?

Egalement, à quoi correspond SolarRad_Jour. Est-ce la moyenne des radiations solaire et l'unité est-elle le W/m²

Merci pour vos réponses.

A+
Pascal

[muchistic]

Bonjour

Petite question

A quoi correspond le champs UV_Dose_jour et quelle est sont unité de mesure?
Comment peut-on employer cette données?

Egalement, à quoi correspond SolarRad_Jour. Est-ce la moyenne des radiations solaire et l'unité est-elle le W/m²

Merci pour vos réponses.

A+
Pascal

[jturlier]

A quoi correspond le champs UV_Dose_jour et quelle est sont unité de mesure?

Salut Pascal,
UV_dose n'a pas d'unité, c'est un indice dont le maxi est 15 ou 16, je ne me souviens plus.
On n'approche que très rarement l'indice 10 sous nos latitudes de l'hémisphère nord, ( les trous dans la couche d'ozone étant principalement au dessus de l'Océan Indien ).

Pour les radiations solaires, l'unité est bien le watt par m². Le maxi du rayonnement solaire est de 1367w/m².
C'est une quantité instantanée d'énergie, pas une moyenne. Cette quantité théorique ne peut être idéalement atteinte qu'entre les tropiques puisque les rayons solaires doivent être à la verticale (azimut) du point. Partout ailleurs, en fonction de la date, de l'heure de la latitude, ce maximum sera nécessairement inférieur.
Ce qui peut être intéressant d'un point de vue utilitaire, ce sont plutôt les w/h produits par les x m² d'une installation photovoltaïque.

[Météo Villarzel]

Bonsoir,
il ne faut pas confondre les valeurs instantanées et les valeurs qui sont calculée pour un temps x.

L'index UV est une valeur instantanée et n'a pas d'unité vu que c'est un index, à un moment x la valeur de par exemple de 6.7
L' UVdose est l'index sur une période, par exemple 1 jour, et son unité est (MEDs)
C'est le même truc que pour les radiations solaire.
la radiation solaire est à un instant x de par exemple 850 W/m2, maintenant si tu as cette valeurs pendant deux heures, ça va devenir une énergie de ( 2*850W/m2) soit 1700 W/2/h
Donc solarRad_jour est la somme de l'énergie pendant une journée.

C'est comme ta perceuse qui est affichée sur l'étiquette 1500W, c'est la consommation instantanée à un moment x, si tu l'utilise pendant deux heures, tu vas avoir une consommation de 3000W.

Par la même, les valeurs facteur vent et humidex sont aussi des index calculés et non mesurés et ils n'ont pas d' unités.
Tu n'as pas un facteur vent de -10°C, mais de -10

A+

[PascalWMR]

Bonsoir

Merci bien pour toutes ces explications. C'est plus clair maintenant.

A+