Bonjour à tous !  
 
J'ai déjà fait quelques petits projets autour d'une base de données, mais du très basique et donc je n'ai pas une grosse expérience en bdd. Là j'ai un truc un peu plus costaud à faire et c'est pas très clair dans ma tête au niveau de la manière optimale d'organiser mes données. Je vais essayer d'être le plus précis possible mais en restant concis. En gras ce sont les termes que je reprends plus loin pour les données en bdd.
 
La 1ere pièce de mon système c'est un boîtier électronique qui fait des acquisitions de données et différentes choses, et qui vont venir poster régulièrement des données sur mon serveur. En l'occurrence : des mesures à intervalles réguliers, des codes d'erreur quand il y a un problème, des codes d'événement quand il se produit quelque chose.
 
Ces boîtiers servent à effectuer des traitements électrochimiques.
Ces traitements électrochimiques s'effectuent dans certain lieux, qui peuvent être n'importe où dans le monde.
 
Donc je peux avoir dans le monde plusieurs lieux de traitement.
Dans chaque lieu je peux avoir plusieurs traitements.
Et à chaque traitement est associé à un boîtier.
 
Quand un traitement est terminé, les données le concernant (mesures, erreurs, évènements) sont "archivées", en fait elles restent simplement dans la base de donnée, c'est juste qu'il n'y a plus de boîtier associé à ce traitement (il va servir pour un nouveau traitement), et donc plus aucun postage de donnée ne vient alimenter ce traitement.
 
Le but du jeu c'est que sur le serveur on puisse avoir la représentation complète des traitements (qu'il soit terminé ou non), et pour chacun d'entre eux afficher l'historique des mesures, des erreurs, des évènements, etc...
 
Jusque là, ça va, l'architecture est simple et pour représenter tout ça en BDD, j'ai besoin d'une base de donnée dans laquelle j'ai 3 tables contenant quelques infos pour représenter la configuration complète :
 
Table Lieux : ID unique | Nom du lieu | Adresse du lieu | Photo du lieu | Latitude du lieu | Longitude du lieu
(Latitude et longitude c'est pour les représenter sur une carte google map, ça devrait être sympa !)
 
Table Traitements : ID unique | ID unique du lieu ou s'effectue le traitement | N° de l'objet en traitement | Description de l'objet
 
Table boîtier : ID unique | ID unique du traitement associé à ce boîtier | Adresse mac du boîtier | Date de première mise en service du boîtier
 
Jusque là tout me semble clair et logique, et faire les pages de configuration pour créer/effacer/modifier des lieux, des traitements, ou des boîtiers, ainsi qu'associer un traitement à un lieu, et un boîtier à un traitement, je sais à peu près faire (en php/mysql) !
 
Vous allez me dire il est où le problème alors !!??
Et bien il est dans la phase suivante, quand les boîtiers sont installés et qu'il vont poster des données sur le serveur. A intervalles réguliers les boîtiers vont poster une série de mesures (+timestamp), a chaque évènement ils vont poster le code d'évènement (+timestamp), et à chaque erreur ils vont poster le code d'erreur (+timestamp).
 
Dans les posts les boîtiers précisent leur adresse mac pour qu'au niveau du serveur je sois capable de dispatcher les infos aux bons endroits dans la base (vers les données du traitement auquel le boîtier est associé).
Mon problème est là, je ne sais pas comment organiser dans la bdd de façon logique et optimale toutes ces quantités de données que je vais recevoir !!!
 
A priori je vois 3 solutions :
 
1)
 
Avoir une table "Mesures" (id traitement, timestamp, valeur 1, valeur2, valeur3, etc...), une table "Evenements" (id traitement, timestamp, code) et une table "Erreurs" (id traitement, timestamp, code), et mettre "en vrac" dedans tout ce qui arrive des boîtiers. A chaque post, d'après l'adresse mac du boîtier j'en déduis à quel traitement il correspond et je récupère "l'id traitement", et je rajoute un enregistrement à la table correspondante au type de post (mesures, évènements ou erreurs).
 
2)
 
A chaque fois qu'un nouveau traitement est crée, je crée également 3 nouvelles tables, avec l'id du traitement dans le nom des tables pour les différencier : Mesures_IdTraitement, Evenements_IdTraitement et Erreurs_IdTraitement. A chaque post, d'après l'adresse mac du boîtier j'en déduis à quel traitement il correspond, je récupère "l'id traitement", je construis le nom de la table dans laquelle je vais devoir faire un enregistrement, et je procède à l'enregistrement dans la bonne table correspondant au bon traitement.
 
3)
 
A chaque fois qu'un nouveau traitement est crée, je crée une nouvelle base appelée par exemple Datas_IdTraitement, dans laquelle je crée mes 3 tables Mesures, Evènements et Erreurs. A chaque post, d'après l'adresse mac du boîtier j'en déduis à quel traitement il correspond, je récupère "l'id traitement", je construis le nom de la base dans laquelle je vais devoir me connecter, et je procède à l'enregistrement dans la bonne table, Mesures, Evènements ou Erreurs.
 
Je me dit que malgré que la 1ère soit la plus "bordélique" (car toutes les données de chaque traitement sont mélangées dans les mêmes tables Mesures, Evènements et Erreurs), c'est la solution la plus "propre" vu de l'extérieur, puisqu'au final je n'ai que 6 tables (Lieux, Traitements, Boitiers, Mesures, Evènements, Erreurs).
Dans la 2ème solution, si par exemple j'ai 100 traitements je me retrouve avec 3 tables + 3 tables x 100 = 303 tables, et dans la 3ème solution, 3 tables + 100 bases contenant chacune 3 tables.
 
Selon vous, quelle est la meilleure solution ? Et y en a t-il d'autres ? Sur ce genre de besoin y a-t-il une sorte de recommandation particulière ?
 
Tout commentaire sera le bienvenu !
 
Merci et bon week end à tous !  

La troisième solution serait la création d'une base de données. Dans quelles circonstances ?  Il ne faut pas compter pouvoir faire cela, "à la volée". Cela réclame du temps et des privilèges qui ne sont habituellement pas disponibles en temps réel.
 
La deuxième solution serait la création de tables. Là encore, ce n'et pas une opération qui est sensée être faite au cours d'un traitement interactif, sauf s'il s'agit de tables temporaires.
 
Il reste donc la première solution, qui consiste à définir des tables ayant une structure suffisamment souple pour gérer toutes les situations, et si possible sans contrevenir aux "règles de normalisation" dont, pour rappel, la première dit qu'il ne faut pas mettre des données de types différents dans un même champ.

 
Salut
 
Déjà les solutions 2 et 3 sont absolument à proscrire. On ne crée pas de nouvelle table ou, pire, de nouvelles bdd parce qu'on a de nouvelles infos. On range les infos dans les tables prévues pour les stocker.
 
Ta solution 1 est la bonne. Même si de ton point de vue programmeur elle te semble bordélique, tu t'en fous c'est pas toi qui gère le bordel, c'est ton moteur bdd. Toi, tout ce que t'as à faire, c'est mettre les bons identifiants au bon endroit pour pouvoir retrouver l'info qui aura été dispatchée dans plusieurs tables. Ca sert à ça d'avoir un moteur bdd. Toi, ton seul travail est d'éclater intelligemment tes infos pour qu'il y ait le moins de redondance possible. Ainsi les infos qui vont ensembles dans une relation 1-1 sont dans une même table. Les infos qui sont liées 1-n sont dans 2 tables séparées mais la table qui a "n" info possède l'identifiant de l'info "1" qui lui est reliée. Et les infos qui sont liées n-n sont dans 2 tables séparées et t'as une 3° table qui ne stocke que les identifiants servant à faire le lien...

ouai la 1 c'est plus simple, surtout pas de creer de table en plus,
pour creer ta base utilisé genre mysql workbench tu pourras voir plus facilement ce que ca donne (enfin ca va ta pas beaucoup table). Un petit coup de Doctrine pour le CRUD et vendu (mysql workbench a un plug in doctrine)

Bonjour à tous, et un grand merci pour vos avis éclairés !    
 
Avec le recul du week end, j'en étais arrivé à la même conclusion ! Je ne suis pas en C, je ne dois pas structurer mes données au point de séparer les données de chaque traitement, surtout que toutes ces données sont du même type pour tous les traitements !
 
Donc si je récapitule l'organisation de mes tables et champs dans ma bdd, ça devrait donner ça :
 
Table Lieux : ID unique | Nom du lieu | Adresse du lieu | Photo du lieu | Latitude du lieu | Longitude du lieu
 
Table Traitements : ID unique | ID du lieu où s'effectue le traitement | N° de l'objet en traitement | Description de l'objet
 
Table Boîtier : ID unique | ID dutraitement associé à ce boîtier | Adresse mac du boîtier | Date depremière mise en service du boîtier
 
Table Mesures : ID unique | ID dutraitement associé à cette série de mesures | timestamp | mesure 1 | mesure 2 | mesure 3 | etc
 
Table Evènements : ID unique | ID dutraitement associé à cet évènement | timestamp | code d'évenement
 
Table Erreurs : ID unique | ID dutraitement associé à cet évènement | timestamp | code d'erreur
 
Dans mon fichier php que vont appeler mes boîtiers pour poster des données (avec leur adresse mac dans un des paramètres), j'aurai donc simplement à interroger la table Boîtiers pour determiner l'ID du traitement correspondant, puis à faire un enregistrement dans la bonne table en fonction du type de post (mesure, évènement, ou erreur).
 
Ca me paraît bien, qu'en pensez vous ? J'aime les choses simples, et là je ne pense pas qu'on puisse faire plus simple ?
Après, l'exploitation de ces données pour les afficher sur une belle page oueb, ça c'est une autre histoire, mais comme on dit : chaque chose en son temps !!  

t'as toujour le meme nombre de mesure par boitier ?

Oui, c'est figé, chaque série de mesure consiste en 3 tensions, un courant, une puissance, et quelques autres bricoles

ca me semble bien alors

Ok merci pour la confirmation !
J'édite le titre

 
Tu remarques qu'il s'agit presque de la même chose. Dans un des cas tu as un "évènement" et dans l'autre t'as une "erreur". Tu pourrais aussi considérer une "erreur" comme un évènement d'un certain type et la ranger dans la table "évènement"...

C'est drôle, je me suis fait la même réflexion ce matin dans la voiture !!
J'avais conclu que je pouvais dire que les codes inférieurs à 100 ce sont des évènements par exemple, et supérieurs à 100 des erreurs !

dans ce cas la oui ca serai peu etre mieux de mettre dans la meme table

 
Et peut-être qu'une mesure est elle-aussi un évènement lui-aussi un peu particulier et qu'on peut la ranger dans la même table. Toutefois la mesure amène d'autres infos comme les valeurs mesurées et donc ces infos ne seront pas remplies s'il s'agit d'une erreur ou autre évènement qui n'est pas mesure. A partir de là, il y a 2 façons de voir
- soit tu fais une table assez générales pour stocker des évènements (donc où l'info "valeur" restera vide) et des mesures avec valeur
- soit tu ne veut pas de valeur à vide (certains puristes refusent cette possibilité) et tu gardes 2 tables
 
Chaque choix aura des avantages et des inconvénients mais on peut pas décider pour toi...

Ah oui tiens j'avais pas pensé à ça !
 
Dans ce cas je pourrais effectivement une table générale "Data" qui pourrait ressembler à ça :
 
ID unique | ID du traitement auquel est associé l'enregistrement | Type de data | timestamp | valeur1 | valeur2 | valeur3 | etc....
 
Type de data déterminerait s'il s'agit d'une mesure, d'un évènement ou d'une erreur, et les valeurs seraient renseignées ou pas en fonction du type.
 
Je vais réfléchir à la question !

ca doit etre simpa de bosser sur du hardware de ce type, ca marche comment les petit boitier c'est du TCP qui renvoie vers un serveur ?

Oui c'est super sympa ! En fait je suis développeur électronique, et dans ce projet sur la carte électronique du boîtier j'ai mis un processeur ARM9 32 bits cadencé à 200Mhz, 64Mo de SDRAM (100Mhz), et 512Mo de flash. Niveau connectivité je gère l'ethernet, le wifi 802/11G et GSM/GPRS/3G.
 
Et j'ai un linux embarqué qui pédale, du coup tout ce qui est connexion internet wifi/ethernet/3G c'est un jeu d'enfant.
 
Dedans j'ai le trio serveur web lighttpd + php5 + sqlite et ça sert d'interface utilisateur pour la configuration et la supervision directe en local du boîtier.
 
Mais par dessus ça j'ai un serveur central qui va donc récolter les infos de tous les boîtiers existants pour les mettre en forme et à disposition du public sur un site web.
 
Ce qu'il y a d'intéressant c'est que le boulot n'est pas rébarbatif, ça touche à plein de domaines différents. Ca commence par la conception de l'électronique, le routage de la carte, câblage et mise au point hardware des protos, mise en route du linux embarqué, développement de l'applicatif dédiée du boîtier en C (avec une partie dans l'espace utilisateur et une autre dans l'espace noyau), développement des pages embarquées html/php/css avec accès en bdd sqlite, postage de données vers un serveur.
Et sur le serveur, html/php/css/mysql pour mettre tout ça en forme pour le public.
J'en suis donc actuellement à la partie postage des données et stockage en bdd, "restera plus" qu'à exploiter ces données et faire "des belles" (entre guillements car je ne suis pas web designer....) pages web.
 

pas mal tout ca, j'ai fais des étude en électronique aussi, mais jusqu'a maintenant j'ai jamais bossé sur un système complet embarqué, je me suis arrêté au dev web,
 
pas mal le coup du linux, c'est vrai qu'avec ca on se fait mon chié que de développé un mini OS exprès surtout que y'a pas besoin de gros proc,
 
au niveau interface t'as été voir du coté de Flex, tu peu facilement faire des datagrid

Houlà, j'ai jeté un oeil, ça a l'air super lourd non !?

oui y'a un petit temps d'apprentissage,
mais avec PHP en passant par l'amf
 
imagine coté PHp une fonction qui te return  juste un array avec tout t'es donnée dedan  
 

 
sous flex tu feras  
 
<datagrid data="masuperFonction"></datagrid>
 
et la t'aurai un beau tableau avec tout dedan, pagination, tri....

Mais flex ça consiste en quoi côté navigaterur ? Une applet flash c'est ça ?

ouai c'est que du flash

Je crois que je vais rester sur l'ancienne méthode, générer mes tableaux en php, je suis moyennement chaud pour étudier une nouvelle technologie maintenant

Bonjour à tous !
 
Bon j'ai un nouveau petit casse tête à résoudre
 
J'ai donc à présent ma table "Evenements", qui a la structure suivante :
 

 
 
J'ai rajouté un champ "comment", car dans la page qui permettra de lister les évènements, l'utilisateur aura la possibilité d'éditer un évènement pour ajouter un commentaire.
Par exemple s'il y a un évènement "Appui sur le bouton d'arrêt d'urgence", l'utilisateur pourra après coup expliquer pourquoi il a appuyé sur l'arrêt d'urgence. Ca permettra une traçabilité parfaite de tout ce qui se produit pendant le traitement.
 
J'ai également rajouté un champ "data", car j'ai prévu un évènement un peu spécial, l'évènement "photo". Par l'interface web du boîtier, l'utilisateur pourra poster une photo, qui sera stockée en bdd dans la table évènements. En traitant la photo comme un évènement, ça me permet d'avoir la date et de pouvoir rajouter un commentaire explicatif à la photo. En plus j'ai un port usb maitre sur le boitier, et dans le futur il y aura une webcam branchée, permettant de prendre une photo à intervalle régulier. Du coup la notion d'évènement pour la gestion des photos me semble interressante et logique.
 
Donc mon but à présent c'est d'écrire une page "journal.php", qui va me permettre de lister les évènements, avec un petit moteur de filtres, permettant par exemple de n'afficher que certains codes d'évènements, ou bien d'indiquer une plage de date.
Du coup en haut de la page j'aurai un certain nombre de case à cocher en fonction des évènements à afficher ou non, 2 champs avec un calendrier en popup pour sélectionner une plage de date, et un bouton "afficher".
Et il apparaîtrait alors un tableau de ce style (les évènements sont d'actualité ) :
 
 

 
 
 
 
Jusque là je pense m'en sortir sans trop de problème, mais le souci c'est que dans ce tableau je voudrais rajouter des choses qui n'ont rien à voir avec la table "Evenements"
Dans le boîtier il y a pas mal de paramètres (des consignes de tension, de courant, etc...), et les paramètres sont stockés dans une table nommée "Paramètres", dont voici la structure :
 

 
 
Actuellement, à chaque modification d'un paramètre (dans la page dédiée à  la configuration des paramètres du boîtier), je rajoute un enregistrement à cette table, avec le nom du paramètre qui a été modifié, et sa nouvelle valeur. Mon applicatif quand il a besoin d'un paramètre il va chercher le tout dernier enregistrement correspondant à ce paramètre pour avoir la dernière valeur en date.
Dans mon esprit, je m'étais dit que fonctionner comme ça me permettrait dans le futur d'avoir un historique complet de chaque modification de paramètre par l'utilisateur. C'est aussi une sorte de sécurité, si le traitement électrochimique tourne mal, on peut démontrer que c'est la faute de l'utilisateur qui a mis des valeurs de paramètre erronées
 
Du coup je pense que vous avez compris mon souci, je ne vois pas bien comment je pourrai faire pour tout afficher dans le même tableau en ayant la continuité des dates, par exemple :
 

 
 
 
Ca me semble difficile à réaliser non ? En tout cas je ne vois pas bien comment faire !
Ou alors il faudrait que je considère la modification d'un paramètre comme un évènement (ce qui semble logique dans un sens), mais alors il faut que je modifie ma table évènement pour rajouter 2 champs, "parameterName" et parameterValue", qui ne seraient renseignés que si le code d'évènement correspond à une modification de paramètre.
Et c'est ça qui me gène, au final ça fait des champs qui sont utilisés ou non en fonction du code d'évènement, je ne sais pas si c'est très propre et s'il est "habituel" de structurer sa bdd de cette manière Vous me direz j'ai bien rajouté un champ "data" qui ne sert que quand l'évènement correspond à une photo...
 
Sinon une idée qui me vient, peut-être que je peux garder ma table "Paramètres" comme elle est actuellement, mais modifier ma page de gestion des paramètres pour qu'en plus d'ajouter un enregistrement dans cette table quand l'utilisateur modifie un paramètre, je rajoute également un enregistrement dans la table "Evènements", avec le code indiquant un changement de paramètre, et en renseignant le champ "data" avec l'id unique de l'enregistrement qui vient d'être fait dans la table "Parametres" !?
 
Ca serait plus propre de fonctionner ainsi ?
 
C'est un peu confu dans mon esprit pour l'instant !!

J'ai remis en forme le message ci-dessus....

je rajouterais une table "config" (id, date) et une table de liaison entre "config" et "paramètres".
A chaque modification de paramètres, tu crées un enregistrement dans config + et ceux qui vont bien dans la table de liaison.
Dans ton "evenement", tu rajoutes une FK sur l'id config alimenté par l'id de celle en cours au moment de l'evenement.
 
Par ailleurs en regardant ta table evenement (date de modification), j'en deduis qu'un evenement peut-être modifié.
S'il y a possibilité d'avoir plusieurs "data" ou "comment", je créerai des tables séparées pour ces données avec une FK sur evenement.
 

Bon alors à la première lecture j'ai pas compris, j'ai pas encore assez de connaissance en bdd    
Je creuse ton idée et je reviens    
 

Exact, en fait uniquement le commentaire peut être ajouté ou modifié. Ca permet de rajouter un commentaire éventuel à un évènement.
Mais cette modification se fait sur le boîtier, par son interface web. Et du coup il me faut un moyen pour savoir qu'un champ a été modifié et qu'il faut le reposter vers le serveur pour qu'il soit également mis à jour sur le serveur qui centralise toutes les données de tous les boitiers.
 
Dans le boîtier il y aura un processus en tache de fond qui va régulièrement regarder si un enregistrement a son timestamp "lastModification" supérieur au timestamp du dernier enregistrement posté vers le serveur. Comme ça à chaque nouvel enregistrement ou si un enregistrement est modifié, ils seront automatiquement détectés et (re)postés vers le serveur.

ouais bon j'ai pas été super clair non plus    
table "config"

table de liaison config<=>paramètre "l_config_parametre"

exemple d'utilisation, admettons que tu aies une premiere config (id=1) avec 3 paramètres (id=1,2,3)
contenu de l_config_parametre:

tu modifies le paramètre 2 (qui devient donc id=4) et en même temps tu crées une config (id=2)
contenu de l_config_parametre:

Grace à tout ça tu peux facilement trouver la config "en cours" (celle qui a le plus grand id) et tous les paramètres associés via un select sur l_config_parametre.
 
Après dans ta table evenement, tu rajoutes un id_config alimenté par la config "en cours" au moment ou l'evt est créé.
Tu peux ainsi retrouver tous les paramètres tels qu'ils étaient au moment de l'evenement ...

Ok j'ai compris !
 
En fait je ne comprenais pas bien le pourquoi d'une table config ainsi que d'une table de liaison. A vrai dire je n'ai besoin ni de l'une ni de l'autre, car je n'ai pas besoin de mémoriser un ensemble de valeur de paramètres sous la forme d'une "config" !    
 
Chaque paramètre est indépendant, j'ai juste besoin d'avoir l'historique de chaque modification de chacun d'entre eux.
Du coup ce midi j'ai réfléchi un peu en cassant la croûte, je me suis dit qu'il faudrait que la table d'évènement soit générique pour pouvoir afficher des types de données différents dans ma page journal, et je pense avoir une idée simple et assez logique :
 
 
Structure table "Paramètres"
 

 
Structure table "Photos"
 

 
Structure table "Evènements"
 

 
- Au niveau des évènements internes du boîtier (démarrage/extinction, bouton d'arrêt d'urgence appuyé/relaché, etc...), je n'ai pas de donnée supplémentaire, juste un code d'évènement, il suffit que je rajoute un enregistrement dans la table "Evènements" en laissant le champ "event_id" vide.
 
- Sur la page d'upload de photo, je mets un champ pour selectionner le fichier, un champ pour mettre un commentaire, et il me suffit alors de créer un enregistrement dans la table "Photos" pour stocker la photo, de récupérer l'id unique de cet enregistrement, et de faire un autre enregistrement dans la table "Evenements", en indiquant le code d'évènement correspondant à une photo, et en renseignant le champ event_id avec l'id unique de la photo.
 
- Sur la page de gestion des parametres même principe, à chaque modification d'un paramètre je rajoute un enregistrement dans la table "Paramètres" avec le nom du parametre et sa valeur, je récupère l'id de cet enregistrement, puis je fais un enregistrement dans la table "Evènements" en indiquant le code d'évènement correspondant à une modification de paramètre, et en renseignant le champ event_id avec l'id unique de l'enregistrement du paramètre correspondant.
 
Du coup dans ma page journal.php, avec une seule requete sql je peux récupérer la liste des évènements qui m'interessent en filtrant les codes d'évènement et les plages de date.
Ensuite dans la construction dynamique de mon tableau, je peux formatter les cases de la colonne "Evènement" en fonction du code d'évènement de la ligne et en allant chercher les données correspondantes : pas de donnée pour les évènements simples, nom et valeur pour une modif de paramètre, photo pour une photo.
 
En plus l'utilisateur peux toujours mettre un commentaire à une photo ou sur une modification de parametre dans le journal    
 
Par contre c'est peut être pas super optimisé dans le sens où si par exemple dans le futur je mets un diaporama permettant de voir toutes les photos enregistrées dans la table "Photos" et que je veux afficher les commentaires correspondants, il faut que je fasse un "SELECT comment FROM Evenements WHERE event_id = xxxx"
Avec le xxx correspondant à l'id unique de la photo en cours de visualisation.
J'imagine que le moteur bdd doit scanner tous les enregistrements pour trouver le commentaire correspondant, mais bon, je ne pense pas que ça soit trop génant dans mon cas, je n'aurai pas non plus des millions d'enregistrements dans ma table Evenenement, et un seul utilisateur connecté à la fois sur le boîtier    
 
C'est pas trop déconnant si je pars là dessus ?  

J'avais pas bien compris la 1ere fois... et je suis pas sur d'avoir mieux compris la 2eme
 
Maintenant pourquoi je pensais à une table config : admettons que tu aies un evt "plantage", j'imaginais que tu avais besoin de récupérer l'ensemble des paramètres à ce moment là. Si c'est pas le cas tant mieux!
 
Bon maintenant si je resume :
- tu as des evenements (divers)
 + chaque evenement a ses informations
 + eventuellement une (ou plusieurs?) photos
- par ailleurs tu as des paramètres
 + a un instant donnée chaque paramètre à une valeur
 + la modification de la valeur d'un paramètre engendre la création d'un evenement
 
Si c'est bien ça je ferais comme ça:
parametre

note: cette table te donne la liste des paramètres de ton bouzin, elle n'est jamais censé être modifiée par qui que ce soit (sauf toi).
evenement

photo

note: pas besoin d'avoir le blob et le chemin du fichier, choisis l'un ou l'autre.
l_parametre_evenement

l_photo_evenement

note: normalement une table de liaison n'est utile que si une photo peut être liée à plusieurs evenements. Si c'est pas le cas, vire cette table et rajoute une FK dans photos sur evenements.
 
ça peut te paraitre compliqué comme ça, mais en fait non
exemple tu veux la l'historique des modifications du paramètre toto:

SELECT
 parametre.name,
 lpe.value,
 evenement.date,
 evenement.comment
FROM
 parametre
 INNER JOIN l_parametre_evenement lpe ON  lpe.parametre_id = parametre.id 
 INNER JOIN evenement ON evenement.id = lpe.evenement_id
WHERE
 parametre.name='toto'
ORDER BY
 evenement.date ASC

Il n'y a pas de plantage
Mais au pire au démarrage suivant les paramètres à ce moment sont de toutes façon les dernières valeurs de paramètres de la bdd.
 
Pour le reste, je comprends mieux maintenant pourquoi tu proposes des tables de liaisons. C'est vrai qu'avec ces tables ça permet de faire vraiment ce qu'on veut en une seule requête SQL.
 
Mais dans mon cas par rapport à ton exemple, je n'ai jamais besoin d'afficher l'historique des modifications d'un seul paramètre.
Par exemple les seuls filtres que j'aurai au début de la page, ça va être quelque chose comme :
 

 
Du coup ma requete de base pour construire mon tableau de résultat est ultra simple et consiste simplement à faire un SELECT date code comment FROM events WHERE code = XX OR code = yy OR code = zz, etc...
Ensuite pour chaque ligne de mon tableau, en fonction du code de l'évènement, soit j'affiche juste un intitulé (appui sur arrêt d'urgence, coupure de courant, etc...), soit j'affiche les données liés au paramètre en ayant pralablement refait un accès bdd pour récupérer le nom du parametre et sa valeur (paramètre XXX passé à YYY), soit j'affiche la photo.

oui mais non
Admettons tu as les evenements suivants : evt1, plantage, evt2, update param1, update param2, evt3.
Dans ton "historique" tu n'veux afficher la config au moment du plantage, tu peux pas
 

quelque chose m'échappe...

Nan mais c'est aussi super simple avec la structure que je donnais plus haut
Tu fais tout en une seule requête et c'est ton traitement qui s'occupe d'afficher les bonnes infos. Si j'ai tout compris à ce que tu veux faire, la requête ressemblerait à ça:

SELECT
      evenement.code,
      evenement.date,
      evenement.comment,
      parametre.name,
      lpe.value,
      photo.name
FROM
      evenement 
      LEFT OUTER JOIN l_parametre_evenement lpe ON  lpe.evenement_id = evenement.id
      LEFT OUTER JOIN parametre ON parametre.id = lpe.parametre_id
      LEFT OUTER JOIN l_photo_evenement ON lhe ON lhe.evenement_id = evenement.id
      LEFT OUTER JOIN photo ON photo.id = lhe.photo_id

en rajoutant un where/order qui vont bien
Et si tu veux que les evts qui ont des photos tu changes les outer en inner (et pareil si tu veux que les modifications de params).

On tourne en rond !!    
 
Par rapport au début de ta réponse et au truc qui t'échappe : je n'ai nullement besoin de connaître les valeurs de l'ensemble de mes paramètres à un instant donné !
 
Je reprends mes explications en détaillant un peu plus.
J'avais mis un exemple de ce que pourrait afficher ma page journal un peu plus haut. Il ne s'agit que d'un journal, une sorte de log quoi, qui liste tout ce qui se produit au sein de mon boîtier. Et tout ce qui se produit au sein de mon boîtier j'appelle ça un évènement.
 
Par exemple, quand le boîtier démarre, c'est l'évènement de code 0, c'est mémorisé dans ma table Evenements avec le timestamp.
Quand le boitier détecte une coupure secteur, c'est l'évènement de code 4, quand le boitier s'éteint parce que sa batterie interne est à plat, c'est l'évènement de code 3.
Quand l'utilisateur appuie sur le bouton d'arrêt d'urgence, c'est l'évènement de code 6, quand il réarme le bouton d'arrêt d'urgence c'est le code 8.
J'ai tout un tas de codes d'évènements comme ça, qui me permettent de tracer tout ce qu'il se passe tout au long de la vie de l'appareil.
Ces évènements sont des évènements "internes", qui sont propres au fonctionnement de l'appareil, et pour les dissocier j'ai seulement besoin de connaître le code d'évènement, il y a un code différent pour chaque évènement interne.
 
Mais en plus de ces évènements, je veux faire apparaître dans mon journal deux autres évènements un peu particulier, qui sont déclenchés par l'utilisateur lorsqu'il est loggué sur l'interface web de l'appareil :
- Quand il modifie la valeur d'un paramètre, je veux tracer sa modification et la faire apparaître dans le journal, mais je veux juste tracer le fait qu'à telle heure, il a modifié tel paramètre en le passant à telle valeur. Je n'ai pas besoin de savoir quels étaient les valeurs des autres parametres à ce moment. Je décide par exemple que cet évènement correspond au code 100.
- Quand il uploade une photo, je veux tracer l'upload et faire apparaitre l'image dans le journal (en miniature). Je décide par exemple que cet évènement correspond au code 101.
 
Ensuite dans le journal, l'utilisateur pourra pour chaque "évènement" rajouter un commentaire s'il le souhaite.
Ca permet d'avoir une sorte de dossier complet du traitement électrochimique de l'appareil, un suivi très précis.  
 
Exemples de ce que je voudrais dans mon journal en fonction des différents filtres appliqués :
 
 
Aucun filtre, j'affiche tous les types d'évènements
 

 
Je ne veux afficher que les évènements "modification de parametres" :
 

 
Je ne veux que les évènements "Photos" :
 

 
Je ne veux que les évènements de fonctionnement internes à l'appareil :
 

 
Donc d'après mon besoin, il me semble que pour construire mon tableau, j'ai juste besoin d'une requête uniquement ciblée vers ma table "Evenements", avec comme condition WHERE certaines valeurs de code d'évènement, ainsi qu'un BETWEEN pour spécifier une plage de date.
Cette requete me retournerait simplement les champs "date", "code", "event_id", "comment", me permettant de formater les colonnes Date/heure/Commentaire de mon tableau.
 
Par contre pour formater la colonne "Evenement", je dois pour chaque ligne lors de la construction de mon tableau tester la valeur "code", pour savoir si :
- C'est un évènement interne auquel cas je fais la correspondance code vers intitulé de l'évènement
- C'est un évènement 100 donc "modification de parametres" donc je dois utiliser le "event_id" pour aller chercher dans ma table "Parametres" le nom du parametre modifié et la valeur qui lui a été attribué.
- C'est un évènement 101 donc une photo, donc je dois utiliser le "event_id" pour aller chercher dans ma table"Photo" la photo. En réalité bien sûr là ça sera une balise <img> pointant vers une url permettant de récupérer dans la table "Photo" l'image correspondant à cet "event_id".
 
 
Bon après la rédaction de ce message et la relecture du tiens, je pense qu'en fait tu voudrais me faire éviter de nouveaux accès bdd lors de la construction de chaque ligne de mon tableau, en récupérant tout d'un seul coup, les champs nom de parametre et valeur ou nom de la photo étant vides quand l'évènement ne correspond pas à une modif de parametre ou à l'upload d'une photo.
Mais le souci c'est ce que ça te parait simple, mais moi je ne maitrise encore les requêtes aussi sophistiquées    
 
De plus dans mon boîtier ma bdd c'est sqlite et je ne sais pas si son moteur gère ces requêtes.

meuuuuh non

Pour le moment ...
T'es sur qu'un jour t'auras pas envie de faire une option "sauvegarder mes paramètres" ou ptêt "exporter" (pour pouvoir reproduire le problème sur une autre plateforme)?

bien compris
 

C'est effectivement l'idée et sqlite supporte les jointures.
En reprenant la structure que je t'ai donné et tes exemples, la requêtes ressemblerait à ça.
afficher tous les evenements entre la date X et Y

SELECT
           evenement.code,
           evenement.date,
           evenement.comment,
           parametre.name,
           lpe.value,
           photo.name
FROM
           evenement
           LEFT OUTER JOIN l_parametre_evenement lpe ON  lpe.evenement_id = evenement.id
           LEFT OUTER JOIN parametre ON parametre.id = lpe.parametre_id
           LEFT OUTER JOIN l_photo_evenement lhe ON lhe.evenement_id = evenement.id
           LEFT OUTER JOIN photo ON photo.id = lhe.photo_id
WHERE
           evenement.date >= X
           AND evenement.date <= Y

Si maintenant tu veux afficher que les modifications de paramètres (code=100 si j'ai tout compris), tu rajoutes à la fin

AND evenement.code = 100

pour les photos:

AND evenement.code = 101

pour les evenements "systeme":

AND evenement.code <= 10

A chaque fois ta requête remontera les mêmes colonnes, le traitement des données en sera facilité et tu n'as pas à re-requêter pour chaque ligne.
 
Maintenant, si le concept des jointures t'échappe y'a un topic de MB qu'est pas mal du tout et hésite pas à poser des questions

Ok j'y vois plus clair, effectivement c'est pas mal dans le sens où en une seule requête je récupère toutes les infos dont j'ai besoin pour construire le tableau.
 
Par contre dans ta requête, c'est quoi lpe et lhe ?

des "alias" sur les tables l_parametre_evenement (lpe) et l_photo_evenement (lhe) parce que je suis féignant et que je voulais pas tout ré-écrire à chaque fois

ok !
 
Je suis en train de lire ton lien vers le topic de MB, c'est bien expliqué. Mais dans son exemple de fiche client, il fait un exemple de jointure sans avoir de table de liaison.
 
Donc imaginons dans mon cas les structures de table que j'imaginais au départ, mais avec 2 clés étrangères dans EVENTS, une vers la photo correspondante, l'autre vers le paramètre modifié correspondant :
 
Table PARAMETERS :
 

Table PHOTOS :
 

table EVENTS :
 

- Quand dans mon boitier j'ai un évènement interne ( disons <=10), je rajoute un enregistrement dans la table EVENTS en renseignant "code" et je laisse parameter_id ainsi que photo_id vides.
 
- Quand l'utilisateur modifie un parametre dans l'interface web du boitier, je rajoute un enregistrement dans la table PARAMETERS avec le nom du parametre et sa nouvelle valeur, et j'ajoute un enregistrement dans la table EVENTS en renseignant "code" (100), et renseignant parameter_id avec l'id de l'enregistrement que je viens d'effectuer dans la table PARAMETERS. Je laisse le champ photo_id vide.
 
- Quand l'utilisateur uploade une photo dans l'interface web duboitier, je rajoute un enregistrement dans la table PHOTOS avec les data de la photo, et j'ajoute un enregistrementdans la table EVENTS en renseignant "code" (101), et renseignant photo_id avec l'id de l'enregistrement que je viens d'effectuerdans la table PHOTO. Je laisse le champ parameter_id vide.
 
La question c'est est-ce qu'avec ces 3 tables et le fonctionnement que je décris je peux ensuite également faire une seule requête pour sortir toutes les données d'un seul coup lors de la construction de mon tableau ?
 
Je sais je suis lourd mais j'aimerai bien garder ces structures de table sans rajouter de table de liaison    
Car quand je navigue dans mes données avec sqlitemyadmin c'est visuellement très clair : dans PARAMETERS chaque enregistrement contient le nom du parametre et sa valeur associé, dans la table PHOTOS j'ai toutes mes photos, et dans la table EVENTS, j'ai mas liste de tous les évènement, avec l'id du parametre ou de la photo correspondant(e) lorsqu'il s'agit d'une évènement "modification de parametre" ou d'un "upload de photo".

prex!
 
Une table de liaison est "necessaire"' quand tu as une liaison n-n entre deux entités.
Exemple :  
- un eleve a plusieurs (n) professeurs
- un professeur a plusieurs (n) élèves.
Si tu es sur d'avoir une relation 1-n, elles sont inutiles et à ce moment, comme tu l'as fait pour photos, on place une clé étrangère dans la table principale.
exemple:
- une classe a plusieurs élèves
- un élève a une seule classe (donc fk dans eleve sur classe_id)
 
Maintenant dans ta structure:
"photo"
Une liaison 1-n pourquoi pas mais pas dans le sens ou tu l'as fait
Si un jour tu veux mettre deux images sur un evenement tu pourras pas. Donc la FK va sur photo!

Maintenant si tu es certain qu'une photo ne peut appartenir qu'a un évènement et qu'un évènement peut avoir "au plus" une photo, pourquoi ne pas mettre directement les colonnes dans la table evenement?
Par ailleurs, je suis pas fan des blobs dans les bdds, mais peut-être que sur ta problématique c'est plus adaptée...
 
paramètre
Là je suis pas d'accord parce que tu retrouves avec plusieurs fois chaque paramètre.
Je n'y mettrais que le "name" et stockerai l'historique dans ... une autre table.
Et comme (pour moi) :
- un param peut "subir" plusieurs modifications(=event)
- un event peut concerner plusieurs params (sinon lorsque la modif de 2 params en même temps engendre la création de 2 events)
Je ferais quand même une table de liaison event<=>parameter.
 
Enfin tout ça ne reste que mon humble avis
 

On avance !
 
Dans mon cas, un évènement ne peut correspondre qu'à une seul chose et donc être lié à une seule photo ou une seule modification de paramètre. En gros c'est même pas du n-n ou du 1-n mais presque du 1-1 !!
 
- 1 évènement = 1 photo
- 1 évènement = 1 modif de paramètre
et inversement !
 
Si l'utilisateur modifie plusieurs paramètres d'un coup sur la page de gestion des paramètres, j'aurai effectivement plusieurs évènements, chacun portant sur un seul paramètre. C'est bien le comportement que je souhaite, ou en tout cas il ne me pose aucun problème ! J'aurai simplement plusieurs lignes dans mon tableau journal avec la même date et la même heure, ce n'est pas gênant du tout.
 
Par rapport à ma structure de table "Parameters", effectivement je me retrouve avec plusieurs fois le même paramètre (en tout cas le même nom). Mais ça ne me dérange absolument pas, car quand mon boîtier veut connaître la valeur actuelle du paramètre, je fais un "SELECT value FROM parameters WHERE name = $parameterName ORDER BY ROWID DESC LIMIT 1;"
En clair ça prend la dernière valeur en date de ce paramètre, qui est la valeur en cours, puisque la dernière valeur saisie par l'utilisateur.
 
Je dirai même qu'à la base c'était le comportement que je voulais, car ça me permet dans mon application de rajouter des paramètres sans avoir à modifier quoi que ce soit au niveau des structures des tables !
 

C'est ce que je voulais faire au départ mais ça me semble moins propre que de mettre l'id de la photo et stocker la photo dans une autre table.
Car sinon pourquoi ne pas stocker aussi dans ce cas les données concernant les modifs de parametres (nom et valeur) dans la table EVENTS ? Et si un jour par exemple je rajoute un code d'évènement qui correspond à quelque chose nécessitant 30 valeurs, je trouve plus propre de stocker ça dans une nouvelle table à part et de seulement rajouter dans ma table EVENTS une clé etrangère vers l'id adéquat de la nouvelle table.
 
En tout cas merci beaucoup de prendre le temps de me répondre, j'apprends beaucoup de tes réponses car je comprends parfaitement le pourquoi de ce que tu me propose, et les avantages qui en découlent. Tes propositions permettent de considérer des liens plus complexes entre photos/event et modification parametres/events.
 
Mais c'est vrai que dans mon cas je m'étais fixé un besoin très simple, justement dans le but de me simplifier au maximum la gestion bdd, dans laquelle je débute et dans laquelle je ne me sens pas du tout à l'aise !!
 
Donc dans mon "cahier des charges" du départ, un évènement ne peut être associé :
- Soit à rien si c'est un évènement interne ( code <=10)
- Soit à une seule modif de parametre ( code = 100)
- Soit à une seule photo ( code = 101)
 
Ensuite pour le blob, je comptais partir la dessus car je me disais que pour mon processus qui scrutera les nouveaux enregistrements pour les répercuter sur le serveur central en les postant, ça serait plus simple car il ne s'agirait que d'enregistrements en bdd.
 
Si je ne stocke pas les photos sous forme de blob mais que je les stocke sous forme de fichier (avec le chemin stocké en bdd), ça signifie que je dois aussi synchroniser le dossier photos avec le serveur, et que je dois sur le serveur avoir un dossier de stockage différent pour chaque appareil. Et je me disais que ça simplifiait aussi la gestion des noms identiques. Comme l'utilisateur pourrait poster sur le boitier 2 photos différentes avec le même nom, ça veut dire que je dois dans tout les cas faire un renommage de la photo en rajoutant la date et l'heure ou autre pour dissocier les 2 images.
 
Avec le blob il me suffisait dans la page d'upload de photo de réceptionner l'image, créer la miniature, et stocker les données dans un nouvel enregistrement dans la table PHOTO puis rajouter un enregistrement dans la table EVENTS.
 
Y a t-il une raison particulière qui fait que tu n'es pas très fan pour stocker des données blob dans une bdd ?

Si c'est du 1-0,1 en théorie tu balourdes tout dans la même table avec les champs en question nullable.

L'argument "je sais ecrire la requête qui remonte l'info que je veux malgré une structure bancale" est difficilement recevable
La même requête avec "ma" structure donnerait:

SELECT          
          lpe.value
FROM
          evenement
          INNER JOIN l_parametre_evenement lpe ON  lpe.evenement_id = evenement.id
          INNER JOIN parametre ON parametre.id = lpe.parametre_id
WHERE 
          parametre.code = 'XXX'
ORDER BY
          evenement.date DESC
LIMIT 1

Sauf que les données appartiennent à qui elles devraient
La date est celle de l'evenement, le code celui du paramètre et la valeur celle qui relit les deux.

ouais mais non... pour moi ajouter un paramètre c'est :
- ajouter une entité paramètre (insert dans "parametre" )
- créer un evenement "initialisation du parametre" (insert dans evenement)
- lui affecter sa valeur initiale (insert dans lpe)

J'ai vu trop de systèmes qui au départ étaient "juste un petit truc, on va pas se compliquer la base" impossibles à maintenir/faire evoluer à cause de la structure de la bdd pour pas raler ...
A la question "comment organiser mes données de façon optimale" je réponds "pas comme tu es en train de le faire" mais l'essentiel c'est que tu arrives à faire ce que tu veux

Sur un "petit projet web", la flemme de pas pouvoir faire href="lechampsdelabase" (et j'aime pas trop le binaire direct dans l'html)
Sur un "gros" projet, le fait que la base peut vite prendre des proportions dementielles (et pb sur backup/restore) + ne pas avoir la main sur le stockage des fichiers.

Ok compris ! Mais ça m'embête, si un jour je dois intégrer un évènement lié à beaucoup de données ça me fera une pagaille de champ dans la table EVENTS    
 
 

SELECT          
          lpe.value
FROM
          evenement
          INNER JOIN l_parametre_evenement lpe ON  lpe.evenement_id = evenement.id
          INNER JOIN parametre ON parametre.id = lpe.parametre_id
WHERE 
          parametre.code = 'XXX'
ORDER BY
          evenement.date DESC
LIMIT 1

Ben vu de mon côté de programmeur C embarqué, ça n'est pas bancal    
Car dans mon applicatif, quand j'ai besoin de récupérer la valeur d'un paramètre, il me semble plus logique de le récupérer dans une table de paramètre toute bête, plutôt que de faire une requête qui fait aussi référence à une table d'évènements.
La table d'évènement à mon sens n'étant qu'une "couche" plus haut niveau qui englobe le nom du paramètre modifié et sa nouvelle valeur, et rajoute un timestamp et un commentaire éditable.
Du point de vue "couche applicative", au niveau de la couche paramètres je n'ai pas besoin (et d'ailleurs on ne peut pas si le code est bien écrit) d'avoir ou récupérer des infos de la couche au dessus. Du coup j'ai tendance à structurer ma base avec le même type de raisonnement    
 
 

Oui j'ai bien compris    
Mais toujours depuis mon point de vue de soft embarqué, une table de parametre c'est un peu comme un fichier de config avec une liste de "parametre=valeur".
Si je veux mémoriser un nouveau parametre, je rajoute une ligne nouveauParametre=valeur.
Derrière l'applicatif lit le fichier, si le parametre qu'il cherche n'y est pas, j'initialise à la valeur par défaut et je rajoute la ligne à la fin du fichier "parametre=valeur par defaut".
Effectivement dans le cas d'un fichier il serait idiot à chaque modif de parametre de rajouter une ligne dans le fichier plutôt que de modifier la valeur sur la bonne ligne.
Mais dans mon cas ça à l'avantage de pouvoir faire un suivi des modifications ET de ne pas toucher la structure d'une quelconque table si je dois gérer un nouveau parametre, je rajoute juste un enregistrement avec le nom du nouveau parametre et sa valeur par défaut.
 

Je suis confronté au même problème en programmation embarqué, les clients sont spécialistes pour faire évoluer le cahier des charges au gré des avancements    
Du coup il faut coder intelligemment.
Mais dans le développement dont il est question ici, c'est moi qui établit le cahier des charges    
 
 

Ben là en l'occurence si je garde la photo dans un blob, dans mon tableau journal lorsqu'il y aura un évènement photo le code html généré sera :
<img src="image.php?id=XXX&mini=1> avec le id correspondant au numéro unique de la photo dans la table PHOTOS.
Le fichier image.php qui permet de renvoyer l'image au navigateur est déjà écrit ça c'était pas dur    
 
Donc maintenant en considérant que je garde ces structures de tables :
 
Table PARAMETERS :
 

 
Table PHOTOS :
 
 

 
table EVENTS :
 
 

 
 
Y a t-il un moyen en une seule requête de récupérer d'un seul coup les champs event.date, event.code, event.photo_id, parameters.name et parameters.value en filtrant sur "code" et plage de "date" ?
Vu que dans la génération de mon tableau "journal" je n'ai pas besoin du blob de l'image (photo_id suffit pour générer ma balise <img> ), le truc vicieux avec les jointures c'est juste pour récupérer parameters.name et parameters.value en fonction de event.parameter_id.