Reprise du message précédent :

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.

En attendant une réponse je vais essayer de la trouver tout seul en faisant joujou dans sqlitemyadmin !

Bon j'ai déjà ça qui marche :
 
SELECT events.date, events.code, events.photo_id, parameters.name, parameters.value
FROM events
LEFT OUTER JOIN parameters ON parameters.id = events.parameter_id
WHERE
events.code = 100

ca marche aussi avec :
 
SELECT events.date, events.code, events.photo_id, parameters.name, parameters.value
FROM events
INNER JOIN parameters ON parameters.id = events.parameter_id
WHERE
...
AND
...
 
C'est quoi la différence entre INNER JOIN et LEFT OUTER JOIN ?
Je crois qu'il va falloir que j'aille potasser le bouquin le SQL pour les nuls

c'est "amusant" ça t'embête pour ça mais pas pour les coups des paramètres
 

Bin demande pas si c'est "bien organisé" et fait à ta sauce    
Tout ce que je dis c'est que j'aurais pas fait comme ça!
 

c'est pas parce que c'est plus simple (pour toi) à coder que c'est mieux. Et par ailleurs ça revient au même avec ce que je te proposais.
 

Sauf que, admettons tu "affiches" 10 evts avec chacun une photo, que va-t-il se passer:
- demande au serveur pour la liste. 1 requête qui remonte dix lignes, pour chaque ligne tu créées donc un src="image.php?id=XXX&mini=1
- le navigateur interprète l'html et fait 10 demandes au serveur pour la page image.php
- chacune de ces demandes fait une nouvelle requête à la base pour remonter les blobs
Je pense que dans ton contexte tu t'en fous mais sinon je trouve pas ça super optimisé
 
 

Je te renvoie au lien du topic de MB sur les jointures, c'est tout bien expliqué.

A vrai dire au début de la discussion je cherchais surtout comment organiser les données au niveau du serveur, qui va centraliser les données de tous les appareils.
Je ne savais pas trop s'il fallait que je crée des tables pour chaque appareil, ou que je crée des tables générales avec les enregistrements mélangés de tous les appareil, avec juste un champ permettant de déterminer à quel traitement appartient l'enregistrement.
 
Au niveau de la bdd locale de chaque appareil, je m'imaginais à peu près comment faire, sauf que je pensais construire mon tableau journal en re-requêtant à chaque ligne, mais maintenant ce n'est plus la peine et c'est très bien.
 
Tu as raison pour ta remarque au niveau des 10 evts avec photo, c'est vrai que pour la construction du tableau je n'aurai qu'une requête, mais après le navigateur fera 10 appels à image.php, faisant donc 10 requêtes à la bdd. Effectivement là c'est un avantage de stocker l'image dans le système de fichier.
 
Bon je vais avancer dans mon code php, les photos je vais faire ça en dernier donc je me laisse un temps de reflexion supplémentaire

D'un autre côté, entre un appel au système de fichier et un appel à la BDD (surtout si on tape dans la PK) je doute que les différences de performances soient si évidentes.
 
Ceci n'engage que moi.

ben disons que ça évite de faire tourner php et ça évite un accès bdd, le serveur web (lighttpd dans mon cas) envoie directement le fichier.
 
Mais bon dans mon cas vu que j'ai grand max un seul utilisateur connecté au boîtier en même temps, c'est sûr que ça va pas changer grand chose !