Mysql jessie et Mariadb stretch

[nexen]

Mon cher bruno,

Pour le coté pédagogique, je comprends mieux l’intérêt des 3 capteurs, Mais par contre pour la base Mysql j'ai les yeux qui saignent... Je compare ton approche à vouloir apprendre à un enfant à pécher .... mais avec une grenade ...

Pourrais-tu essayer de leur montrer une autre technique ?
Si j'ai bien compris, vous avez une date .... Je partirais de là avec comme tu à déjà fais une Primary key sur cet enregistrement.

Tu aurais donc :
create table mesure_pression (
date_mesure timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, <- Date automatiquement à jour
... tes champs ....
primary key (date_mesure )
);
et ensuite, demande leur si il est possible d'avoir une table ou autre chose avec seulement les 30 dernières valeurs sans toucher la table principale
(J'ai regarder la vidéo de tes jeunes, ils en sont largement capable ... d’ailleurs dommage pour celui qu a géré les caméra ... pas de bol le coup de l'armée)
un ptit create view as select ..... order by date desc limit 30 ..... et le tour est jouer le pécheur utilise maintenant la canne à pèche !!
et en plus tu soulage ta SD ...

Je te remercie de m'avoir lu et en tant qu'ancien prof Vacataire en informatique en IUT et Administrateur base de donnée j’espère avoir sauver une MariaDb de la torture .

PS : J'adore le thème de ce lycée et de cette classe, J'aimerai être jeune à notre époque .. pour pouvoir les suivre ... moi j'ai eu droit au VT100 et codage assembleur 68000 ....

[nexen]

@destroy : Non tu as raison, c'est pas std du tout ... cf ma réponse entre temps

[bruno83]

Bonjour
Merci de vos précieux conseils
Pour le ballon on avait conservé l’ensemble des mesures sur la carte sd 64 Giga octets
La suppression c’est pour un de mes TP avec PDO ou mysqli :
Pour faire simple on a un serveur apache/MySQL émulé sur un PC puis avec un logiciel isi Professional qui simule une carte électronique Atmega 324p avec capteur en i2c on peut modifier les valeurs du capteur en live(programme en C) +liaison virtuel rs232+appli python qui écrit sur la base de données ,On crée ainsi une chaine virtuelle pour remplir une base sur le même PC.
la table devient rapidement énorme sur nos pc c’était uniquement pour conserver une petite table lol

puis on refais le même tp en réel avec un pi et des cartes e-blocks matrix

[destroyedlolo]

PS : J'adore le thème de ce lycée et de cette classe, J'aimerai être jeune à notre époque .. pour pouvoir les suivre ... moi j'ai eu droit au VT100 et codage assembleur 68000 ....

Ouai, moi aussi, mais sur des cartes 68k sous OS9
C'est certes plus interessant ce qui est fait maintenant, mais ce qui me gène un peu, c'est que les étudiants ressortent sans savoir "ce qu'il y a derriere". Et abreuvé de java et autres phyton, ils pondent des usines a gaz se soucier des impactes sur les systèmes. Et s'ils ont a bosser dans l'embarqué ou dans des systèmes partagé, ca ne pardonne pas

[Bud Spencer]

la table devient rapidement énorme sur nos pc c’était uniquement pour conserver une petite table lol

Si c’est destiné a des élèves autant leur enseigner les bonnes méthodes dès le début parce qu’après, c’est foutu. Meme si vous n’êtes pas des ‘industriels’, il y a quand meme un minimum de bonnes pratiques fondamentales à respecter, surtout dans l’enseignement …

Solution à tes problème de tables qui deviennent énorme: Tu définis un int auto-incrément comme primary key sur ta table et tu fais un trigger ‘after insert’ qui supprime automatiquement les enregistrements obsolètes (au-delà des 30 derniers pour toi visiblement). Si tu veux pousser le bouchon plus loin et qu’il ni à pas de jointure sur la pk, tu peux aussi programmer un reset d’index au démarrage du sgbd, mais si tu veux mon avis, tout tes élèves seront en retraite bien avant que cela ne soit nécessaire

Ps : Jamais de datetime comme primary key. Si il y a le moindre problème avec l’horloge system (et ça arrive bien plus souvent qu’on ne le pense), il devient alors impossible de réordonner les enregistrements !

[bruno83]

merci pour le trigger je vais utiliser cette solution
A+buno

[nexen]

@Bud
Effectivement sur un pi c'est pas le meilleur : Mais ils ne sont pas dans l'industriel non plus ... Donc je tolère
De toute façon pour moi ce qu'il manque au ballon c'est une RTC Histoire de pas perdre l'heure

Sinon sur mes petits clients, on a pas de perte de date ... sinon on aurait de gros soucis car oui Maria/Mysql est utilisé par des grands fabricants militaires/aéronautique


Par contre .. Franchement vu les données ... 64Go tu va pouvoir en mettre des Millions de lignes (Ma plus grosse table perso fait 12 066 916 rec pour 773Mo avec 12 champs dont 2 Varchar de 30 et le reste du Int/float) C'est mes mesures Meteo (Temp/Hum/UV/Vitesse du vent ...).

Nexen

[bruno83]

erreur sur le gps on a l'heure et date donc aucun souci

[Bud Spencer]

C’est surtout une question de bonne pratique et de respect des impératifs de fonctionnement d’un sgdb relationnel. Quand on définit une pk sur une table, on doit le faire avec la garantie absolue d’unicité de la valeur. Meme sans perte de l’heure system, un timestamp ne garantit pas cette unicité. Il suffit d’un simple réajustement de la date-heure par une synchro ntp ou par une opération d’ajustement manuelle pour que l’on se retrouve avec la probabilité d’une tentative d’inscrire un enregistrement en doublon sur cette donnée. Pour un DateTime qui utilise date-heure du client, c’est encore pire. Rien n’empêcherait à plusieurs clients de passer une requête d’insert avec exactement la meme valeur (en plus de la précision douteuse des différents clients et du meme problème de synchro qu’avec un timestamp du serveur). Ils y a plein d’autres raisons qui font que l’on ne doit pas utiliser ces valeurs comme pk, mais il faudrait écrire un bouquin complet pour toutes les expliquer.

Quand on bricole une petite db avec un client unique, c’est sûr que l’on est rarement confronté à ce genre de problème et on n’y pense meme pas. Mais a bien y regarder, ça ne coute pas plus cher de faire les choses correctement et prendre de bonnes habitudes parce que le jour où l’on est confronté à des environnements plus conséquent, c’est le genre d’erreur qui ne pardonne pas …