GW3.0.Alpha ODBC

[TiToine]

OK merci pour les informations. Je vais tacher de faire ça...ma seule crainte c'est que ce soit compliqué pour l'utilisateur.
Tu utilises quoi comme clés pour ta DB? un timestamp unix?

[jturlier]

Non une date structurée AAAAMMJJHHmm en bigint
Par contre dans la DB du pgm de chargement que j'ai créé pour quelques utilisateurs (VP2, 2300,3600, VWS, W2-550 et xnet, non testé), j'ai la même clé, plus la date en TSUnix et en AAAAMMJJHHmm UTC.
Je pense que si tu dois t'orienter dans la direction DB, il serait plus facile d'utiliser MySQL qui a une doc en français, est installable très facilement avec Wamp.
La seule activité qui serait sous le contrôle de GW serait la création de la/les table(s) et views ce qui n'est pas grand chose
Le très gros avantage de ce système, c'est que tu crées dans les faits une sauvegarde de tes données météo, et qu'en cas de changement de station tu continues à avoir toutes tes données en ligne.
Pour info : requête de création table principale ci-dessous contient 81 colonnes.

Code : Tout sélectionner

 qry As String = "CREATE table   " & I_table & " ( tstamp bigint NOT NULL,recdateUTC bigint,recdateTZ bigint,winddir real,windspeed real,windgust real," & _
            " indoorhumidity real,outdoorhumidity real,indoortemperature real,outdoortemperature real,hioutdoortemperature real,lowoutdoortemperature real,barometricpressure real," & _
           "ch1temperature real,ch1humidity real,ch2temperature real,ch2humidity real,ch3temperature real," & _
            "ch3humidity real,evapotranspiration real,uvindex real,solarradiation real,windchill real,indoorheatindex real,outdoorheatindex real," & _
            "dewpoint real,frostpoint real,sealevelpressure real,barometer3H real,pressurealtitude real,cloudbase real,airdensity real,virtualtemperature real,vaporpressure real," & _
            "windspeedrate real,windgustrate real,indoorhumidityrate real," & _
             "soil1temperature real," & _
            "soil1moisture real," & _
            "leaf1Wetness real," & _
            "soil2temperature real," & _
            "soil2moisture real," & _
            "leaf2Wetness real," & _
            "outdoorhumidityrate real,indoortemperaturerate real,outdoortemperaturerate real,pressurerate real,totalrainrate real,ch1temperaturerate real,ch1humidityrate real," & _
            "ch2temperaturerate real,ch2humidityrate real,ch3temperaturerate real," & _
            "ch3humidityrate real,evapotranspirationrate real,uvindexrate real,solarradiationrate real,windchillrate real,indoorheatindexrate real,outdoorheatindexrate real,dewpointrate real," & _
            "windrundaily real,degdaysheatingdaily real,degdayscoolingdaily real,moonphase real," & _
            "degdaysheatingmonthly real,degdayscoolingmonthly real,windrunmonthly real,degdaysheatingyearly real,degdayscoolingyearly real," & _
             "windrunyearly real,instantrain real ,rain_total real,rain_yearly real ,rain_monthly real,rain_daily real ,rain_hourly real ,last24hrrain real,rainrate real," & _
             "hiuv real,hisolarrad real,CONSTRAINT V" & I_table & "_pkey PRIMARY KEY (Tstamp))"
        'Syntaxe différente Postgresql et Mysql
        If I_drv.Substring(0, 2) = "My" Then
            qry = qry & " ENGINE=InnoDB DEFAULT CHARSET=latin1;"
        End If
        qry = Encode(qry)

Les valeurs non disponibles dans les fichiers sources sont, si les champs nécessaires à leur calcul existent, créées.
Tu peux me contacter directement en cas de besoin.

Jean

[TiToine]

J'ai étudié un peu ça ce matin et Postgres me semble relativement simple à installer finalement. Il suffit juste d'inclure les binaires (14Mo sans pgadmin) dans GW, puis en trois commandes ça marche:
initdb.exe - D \path
createuser -s postgres
pg_ctl.exe -D \path start

Ensuite GW peux créer une table par plugin et populer les champs.


Pour info j'ai recompilé une nouvelle version 3.0.1a dispo sur le post GW3. Pourrais-tu refaire le test de la ligne de commande? et me redonner le log. Merci.

[jturlier]

Bien noté,
Je télécharge, teste et te donne les infos

Ensuite GW peux créer une table par plugin et populer les champs.

Par contre là, j'ai une remarque : pourquoi une table par plugin ?
Chaque plugin possède des data communes et des infos que n'ont pas les autres. Pourquoi quand l'info n'est pas là, ne pas tout simplement l'ignorer.
C'est là que se situe l'un des avantages d'une DB, ça te permettrait de continuer à la remplir quelle que soit la station.
C'est d'ailleurs ce que tu fais avec tes stats : si on change de station sans regénérer complètement les stats, on ne perd pas de données anciennes.

[TiToine]

Je vais y réfléchir.
Sais-tu si un champs qui ne contient pas de valeur prend de l'espace dans la DB? Ce qui me gène c'est que GW a une 60aine de sondes, et j'ai peur que ça prenne beaucoup de place si il faut une colonne par sonde. Imagine un plugin qui ne lirait qu'une sonde, donc ne feed qu'un champs, ça laisse 59 champs vides par enregistrement (~95% d'espace de perdu).

[endmarsfr]

Je vais y réfléchir.
Sais-tu si un champs qui ne contient pas de valeur prend de l'espace dans la DB? Ce qui me gène c'est que GW a une 60aine de sondes, et j'ai peur que ça prenne beaucoup de place si il faut une colonne par sonde. Imagine un plugin qui ne lirait qu'une sonde, donc ne feed qu'un champs, ça laisse 59 champs vides par enregistrement (~95% d'espace de perdu).

C'est l'intérêt des BD, d'optimiser la place disque, et pour postgre, cela dépend, a priori, du typage des données.
Si on utilise des données du type varchar, les données peuvent être de longueurs variables, idem avec avec l'attribut NULL qui permet de spécifier qu'une donnée peut être vide, dans ce cas la place , nécessaire est réduite.
Pour le vérifier, il suffit de le tester en déclarant 2 tables et en utilisant des champs de type "constant" d'un coté et de l'autre des champs de type "varchar" et/ou pouvant être "NULL".

En, tout cas pour ma part, j'approuve l'utilisation d'une BD, j'avais fait un post en ce sens il y a plusieurs mois.

et encore bravo pour cette nouvelle version 3.0.0a dont les perfs sont à l'honneur.

[jturlier]

Antoine,

ne te préoccupes absolument pas du nombre de champs et s'ils sont remplis ou non, les moteurs de bases de données utilisent des algorithmes qui gèrent très bien le contenu ou non des champs.
Comme je te l'ai dit, j'ai une DB dont le volume physique (après vérif) est de l'ordre de 1.7Go, et ma table météo qui est une des plus grosses à 73 champs et 330 000 enregistrements (environ 6 ans à un toutes les 10 min), j'en ai une autre de 80 champs et 120 000 enregistrements (cela correspond à 14 mois de VP2 avec un enregistrement toutes les 5 min), plus une cinquantaine d'autres plus petites. Avant qu'une des tables arrive à des valeurs de plusieurs dizaine de millions d'enregistrements, tu seras à la retraite et moi je reposerai en paix !
Le point qui peut s'avérer bloquant, c'est en fait la taille du disque, pas le nombre d'enregistrements, mais de nos jours "pour quelques To de plus..."

[endmarsfr]

Antoine,

ne te préoccupes absolument pas du nombre de champs et s'ils sont remplis ou non, les moteurs de bases de données utilisent des algorithmes qui gèrent très bien le contenu ou non des champs.
Comme je te l'ai dit, j'ai une DB dont le volume physique (après vérif) est de l'ordre de 1.7Go, et ma table météo qui est une des plus grosses à 73 champs et 330 000 enregistrements (environ 6 ans à un toutes les 10 min), j'en ai une autre de 80 champs et 120 000 enregistrements (cela correspond à 14 mois de VP2 avec un enregistrement toutes les 5 min), plus une cinquantaine d'autres plus petites. Avant qu'une des tables arrive à des valeurs de plusieurs dizaine de millions d'enregistrements, tu seras à la retraite et moi je reposerai en paix !
Le point qui peut s'avérer bloquant, c'est en fait la taille du disque, pas le nombre d'enregistrements, mais de nos jours "pour quelques To de plus..."

tout à fait Postgre fait partie des moteurs sachant gérer de très fortes volumétrie de données et il n'y a pas à s'en inquiéter.
Il faut cependant faire attention à la gestion des index et de à l'écriture de ses requêtes, c'est de là que pourraient provenir les défauts de performance.

[jturlier]

C'est l'intérêt des BD, d'optimiser la place disque, et pour postgre, cela dépend, a priori, du typage des données.

Re bonjour Hugues,
tu as raison sur ce point, mais la plupart des champs vont être soit en int16/32 soit en real (comme tu peux le voir sur un de mes précédents posts, ils sont tous en réel, ça m'évite de réfléchir ), avec sans doute quelques INT64. Quand il n'y a pas de données le moteur met un flag dans une table d'adresses pour indiquer l'absence de données dans le champ correspondant. (Trèèèèèèèès simplifié)
Les types les plus gourmands sont en fait les date, mais ils sont ensuite, aussi bien en C qu'en PHP pas très faciles à traiter.
Bonne soirée

[jturlier]

Il faut cependant faire attention à la gestion des index et de à l'écriture de ses requêtes, c'est de là que pourraient provenir les défauts de performance.

Je n'ai pas le temps de répondre que tu as déjà tiré !
Dans le cas qui nous préoccupe, il ne devrait y avoir qu'une clé et je ne suis pas trop sûr pour les index, car sans liaisons inter-tables, excepté pour des recherches particulières, ça ne devrait pas poser de gros problèmes, mais on pourras en reparler à la réalisation des requêtes.

[endmarsfr]

Il faut cependant faire attention à la gestion des index et de à l'écriture de ses requêtes, c'est de là que pourraient provenir les défauts de performance.

Je n'ai pas le temps de répondre que tu as déjà tiré !
Dans le cas qui nous préoccupe, il ne devrait y avoir qu'une clé et je ne suis pas trop sûr pour les index, car sans liaisons inter-tables, excepté pour des recherches particulières, ça ne devrait pas poser de gros problèmes, mais on pourras en reparler à la réalisation des requêtes.

je serais ravis d'aider si je peux.

Bonne soirée

[endmarsfr]

Re bonjour Hugues,
tu as raison sur ce point, mais la plupart des champs vont être soit en int16/32 soit en real (comme tu peux le voir sur un de mes précédents posts, ils sont tous en réel, ça m'évite de réfléchir ), avec sans doute quelques INT64. Quand il n'y a pas de données le moteur met un flag dans une table d'adresses pour indiquer l'absence de données dans le champ correspondant. (Trèèèèèèèès simplifié)
Les types les plus gourmands sont en fait les date, mais ils sont ensuite, aussi bien en C qu'en PHP pas très faciles à traiter.
Bonne soirée[/quote]

S'il y a des champs qui seront souvent vides (quelques soient leur type, date, int, ...) , cela vaudra le coup de les rendre "nullables" cela apportera un gain de place appréciable.


Bonne soirée

[TiToine]

En fouillant sur google j'en suis arrivé à la même conclusion, mais ça reste un peu flou pour les types du genre "real".

Donc a priori une seule table pour tous les plugins avec le timestamp en clé et une 60aines de colonnes devraient être OK.

[jturlier]

Cela me semble parfaitement correct.

Pour info, les réels n'occupent que 4 bytes, mais ils n'ont que 7 chiffres significatifs (1234567 ou 0,123456) (mantisse 23 et exposant 8 bits). Je ne vois pas trop quelle valeur pourrait nécessiter plus, excepté si tu dois faire des calculs très pointus.
Je reviens sur un point : le timestamp : qu'il soit en clé, je n'y vois aucun inconvénient, cependant si tu visualises le contenu de ta table avec une query directe dans PGAdmin, les timestamps ne sont absolument pas parlants, c'est pourquoi je te conseillerais d'ajouter une colonne avec une date lisible et sur laquelle tu peux faire des traitements.
Autre cas : par exemple essaie de créer une view sur ta table où tu vas pouvoir afficher les maxi, mini, moyennes des températures par jour, avec les timestamps Unix c'est tout à fait impossible, alors qu'avec la structure que je t'ai suggéré, c'est un amusement.

[endmarsfr]

Bonsoir,

Ca y est j'ai migré mes données sous postgresql (V9 sous windows)

J'ai d'abord testé avec la V2.0.312b :
Je n'ai eu que des plantages jusqu'à ce que je convertisse les champs "date" et "time" en char.
J'ai du modifier le format en

Code : Tout sélectionner

%Y-%m-%d

et

Code : Tout sélectionner

%H:%M:%S

pour les champs "date" et "time".

Ensuite, fin de l'aventure sur la V2, j'ai un plantage systématique du Runtime sans message explicite.

J'ai ensuite testé avec la V3.0.2.
Idem, j'ai eu besoin de passer les champs

Code : Tout sélectionner

date

et

Code : Tout sélectionner

time

en char(10) pour que cela fonctionne.
J'ai installé la dll "odbc.dll" avec les messages et pu obtenir un message d'erreur plus explicite :

"la fonction concat(character, unknown, character) n'existe pas"

lors de l’exécution de la requete suivante :

Code : Tout sélectionner

SELECT baro,qnh,date,time FROM wxlog  WHERE CAST(CONCAT(date,'',time) AS DATETIME) BETWEEN '2011-05-15 00:00:00' AND '2011-05-17 00:00:00'

en effet, la fonction CONCAT ne semble pas exister sur postgresql.

Jean, est-tu parvenu à mapper graphweather sur une BD Postgresql via odbc ?
Si oui, pourrais-tu me faire parvenir par MP tes fichiers de conf, la table et un extract de données pour que je comprenne ce qui cloche dans mon environnement ?