-on gère des boitiers qui communiquent 0 à n paramètres (dans l'exemple
j'en met que 2)
-on stocke dans une table historique toutes les communications qui
arrivent
-on dispose dans une table la configuration actuelle
pour l'instant on a :
boitier(_idboit_,num,param1,param2)
historique(_id_,date,idboit,param1,param2,param3,param4)
-on gère des boitiers qui communiquent 0 à n paramètres (dans l'exemple
j'en met que 2)
-on stocke dans une table historique toutes les communications qui
arrivent
-on dispose dans une table la configuration actuelle
pour l'instant on a :
boitier(_idboit_,num,param1,param2)
historique(_id_,date,idboit,param1,param2,param3,param4)
-on gère des boitiers qui communiquent 0 à n paramètres (dans l'exemple
j'en met que 2)
-on stocke dans une table historique toutes les communications qui
arrivent
-on dispose dans une table la configuration actuelle
pour l'instant on a :
boitier(_idboit_,num,param1,param2)
historique(_id_,date,idboit,param1,param2,param3,param4)
Le Wed, 08 Aug 2007 16:01:25 +0200, Gilles RONSIN a écrit:-on gère des boitiers qui communiquent 0 à n paramètres (dans
l'exemple j'en met que 2)
-on stocke dans une table historique toutes les communications
qui arrivent -on dispose dans une table la configuration actuelle
pour l'instant on a :
boitier(_idboit_,num,param1,param2)
historique(_id_,date,idboit,param1,param2,param3,param4)
Avant de regarder de ce côté là, je pense qu'il y a
déjà quelques problèmes de normalisation à évoquer
1) votre n il est constant au cours du temps ? identique pour tous
les boitiers ?
Si vous répondez non à une de ces questions, alors il y a un
problème pour la table boitier.
Comme je dis dans mon cours « un bon schéma n'a pas besoin de
changer au cours du temps », c'est à dire en particulier qu'il ne
doit pas y avoir besoin d'ajouter des attributs (colonnes) plus
tard, parce qu'on se rend compte qu'on en a besoin.
Alors oui, techniquement, on peut changer le schéma d'une table
(ALTER TABLE ...) mais c'est signe d'un problème de schéma bien
souvent. Dans votre cas de figure, si les boitiers n'ont pas tous
le même nombre de paramètres, vous vous retrouverez avec des trous
(NULL) Si vous avez un paramètre à ajouter, il faut créer un
nouvel attribut. Il y a donc peut-être un effort à faire déjà là.
2) même problématique pour l'autre table.
Sans compter les redondances que vous évoquez vous-même.
3) si les *valeurs* de vos paramètres sont discrètes et peu
nombreuses il peut être intéressant de les stocker dans une table
à part et de faire des jointures. Mais cela dépend vraiment des
valeurs (entier ? chaînes de caractères ? etc.) et de l'usage.
Maintenant pour la modélisation, si j'ai bien compris votre
problème (pas sûr, parce que param3 et param4 je ne sais pas ce
que c'est), c'est un cas classique de table mise à jour dont vous
souhaitez conserver les mises à jour.
Il y a en gros deux pistes, chacune avec des avantages et
inconvénients.
A) soit une table d'archivage identique à la table archivée avec
un attribut supplémentaire indiquant quand l'archivage a eu lieu
donc pour vous ca serait en gros (à modifier selon mes dires plus
...
A noter que l'insertion avant le UPDATE peut être faite
automatiquement via une procédure stockée et un déclencheur dans
le SGBD.
B) soit on veut éviter encore plus les redondances, et donc on ne
va archiver que ce qui change.
C'est un peu plus compliqué à mettre en oeuvre, on peut
éventuellement toujours s'en sortir avec un déclencheur, mais en
général on fait ca du coté applicatif
...
L'option B continue de fonctionner même si boitier change de
schéma, alors que dans l'option A il faudra aussi changer le
schéma de boitier_archive (ce qu'on va typiquement oublier de
faire, d'où problèmes après).
Maintenant si vous rassemblez tout cela et que vous souhaitez
gérer un nombre quelconque (dans le temps et l'espace) de
paramètres pour vos boitiers, une seule et même table peut faire
l'affaire (ou non).
boitier (id,nom,param_name,param_value,communication_date)
Si une même communication met à jour plusieurs boitiers, vous
pourriez avoir une table communication avec un id et une date, et
au lieu d'avoir l'attribut date dans boitier cela serait une
référence à l'id de la table communication.
Pour un boitier donné, la configuration actuelle correspond aux
tuples (la ligne) avec la valeur communication_date la plus
élevée. Et vous pouvez gérer autant de paramètres différents que
vous souhaitez : chaque paramètre est dans un seul tuple.
...
Il faut après adapter un peu la logique, ou se baser sur les
fonctionalités de partitions du SGBDR, ou écrire des déclencheurs
pour : 1) créer automatiquement les tables en fonction des besoins
(dès qu'on entre dans un nouveau mois)
2) faire les insertions dans la bonne table
3) selon les sélections, faire des unions
Après réflexion sur le schéma il faut le tester, pour les
performances, il est difficile de les deviner, cela dépend
...
J'espère vous avoir donné quelques pistes de réflexion.
BTW, tout ce qui précède n'a rien de spécifique à MySQL. Ma
réponse est généraliste, et en terme de SGBDR je pense qu'il vaut
mieux essayer de ne pas penser en terme d'un seul moteur. Cela
donne trop de problèmes après sinon.
Le Wed, 08 Aug 2007 16:01:25 +0200, Gilles RONSIN a écrit:
-on gère des boitiers qui communiquent 0 à n paramètres (dans
l'exemple j'en met que 2)
-on stocke dans une table historique toutes les communications
qui arrivent -on dispose dans une table la configuration actuelle
pour l'instant on a :
boitier(_idboit_,num,param1,param2)
historique(_id_,date,idboit,param1,param2,param3,param4)
Avant de regarder de ce côté là, je pense qu'il y a
déjà quelques problèmes de normalisation à évoquer
1) votre n il est constant au cours du temps ? identique pour tous
les boitiers ?
Si vous répondez non à une de ces questions, alors il y a un
problème pour la table boitier.
Comme je dis dans mon cours « un bon schéma n'a pas besoin de
changer au cours du temps », c'est à dire en particulier qu'il ne
doit pas y avoir besoin d'ajouter des attributs (colonnes) plus
tard, parce qu'on se rend compte qu'on en a besoin.
Alors oui, techniquement, on peut changer le schéma d'une table
(ALTER TABLE ...) mais c'est signe d'un problème de schéma bien
souvent. Dans votre cas de figure, si les boitiers n'ont pas tous
le même nombre de paramètres, vous vous retrouverez avec des trous
(NULL) Si vous avez un paramètre à ajouter, il faut créer un
nouvel attribut. Il y a donc peut-être un effort à faire déjà là.
2) même problématique pour l'autre table.
Sans compter les redondances que vous évoquez vous-même.
3) si les *valeurs* de vos paramètres sont discrètes et peu
nombreuses il peut être intéressant de les stocker dans une table
à part et de faire des jointures. Mais cela dépend vraiment des
valeurs (entier ? chaînes de caractères ? etc.) et de l'usage.
Maintenant pour la modélisation, si j'ai bien compris votre
problème (pas sûr, parce que param3 et param4 je ne sais pas ce
que c'est), c'est un cas classique de table mise à jour dont vous
souhaitez conserver les mises à jour.
Il y a en gros deux pistes, chacune avec des avantages et
inconvénients.
A) soit une table d'archivage identique à la table archivée avec
un attribut supplémentaire indiquant quand l'archivage a eu lieu
donc pour vous ca serait en gros (à modifier selon mes dires plus
...
A noter que l'insertion avant le UPDATE peut être faite
automatiquement via une procédure stockée et un déclencheur dans
le SGBD.
B) soit on veut éviter encore plus les redondances, et donc on ne
va archiver que ce qui change.
C'est un peu plus compliqué à mettre en oeuvre, on peut
éventuellement toujours s'en sortir avec un déclencheur, mais en
général on fait ca du coté applicatif
...
L'option B continue de fonctionner même si boitier change de
schéma, alors que dans l'option A il faudra aussi changer le
schéma de boitier_archive (ce qu'on va typiquement oublier de
faire, d'où problèmes après).
Maintenant si vous rassemblez tout cela et que vous souhaitez
gérer un nombre quelconque (dans le temps et l'espace) de
paramètres pour vos boitiers, une seule et même table peut faire
l'affaire (ou non).
boitier (id,nom,param_name,param_value,communication_date)
Si une même communication met à jour plusieurs boitiers, vous
pourriez avoir une table communication avec un id et une date, et
au lieu d'avoir l'attribut date dans boitier cela serait une
référence à l'id de la table communication.
Pour un boitier donné, la configuration actuelle correspond aux
tuples (la ligne) avec la valeur communication_date la plus
élevée. Et vous pouvez gérer autant de paramètres différents que
vous souhaitez : chaque paramètre est dans un seul tuple.
...
Il faut après adapter un peu la logique, ou se baser sur les
fonctionalités de partitions du SGBDR, ou écrire des déclencheurs
pour : 1) créer automatiquement les tables en fonction des besoins
(dès qu'on entre dans un nouveau mois)
2) faire les insertions dans la bonne table
3) selon les sélections, faire des unions
Après réflexion sur le schéma il faut le tester, pour les
performances, il est difficile de les deviner, cela dépend
...
J'espère vous avoir donné quelques pistes de réflexion.
BTW, tout ce qui précède n'a rien de spécifique à MySQL. Ma
réponse est généraliste, et en terme de SGBDR je pense qu'il vaut
mieux essayer de ne pas penser en terme d'un seul moteur. Cela
donne trop de problèmes après sinon.
Le Wed, 08 Aug 2007 16:01:25 +0200, Gilles RONSIN a écrit:-on gère des boitiers qui communiquent 0 à n paramètres (dans
l'exemple j'en met que 2)
-on stocke dans une table historique toutes les communications
qui arrivent -on dispose dans une table la configuration actuelle
pour l'instant on a :
boitier(_idboit_,num,param1,param2)
historique(_id_,date,idboit,param1,param2,param3,param4)
Avant de regarder de ce côté là, je pense qu'il y a
déjà quelques problèmes de normalisation à évoquer
1) votre n il est constant au cours du temps ? identique pour tous
les boitiers ?
Si vous répondez non à une de ces questions, alors il y a un
problème pour la table boitier.
Comme je dis dans mon cours « un bon schéma n'a pas besoin de
changer au cours du temps », c'est à dire en particulier qu'il ne
doit pas y avoir besoin d'ajouter des attributs (colonnes) plus
tard, parce qu'on se rend compte qu'on en a besoin.
Alors oui, techniquement, on peut changer le schéma d'une table
(ALTER TABLE ...) mais c'est signe d'un problème de schéma bien
souvent. Dans votre cas de figure, si les boitiers n'ont pas tous
le même nombre de paramètres, vous vous retrouverez avec des trous
(NULL) Si vous avez un paramètre à ajouter, il faut créer un
nouvel attribut. Il y a donc peut-être un effort à faire déjà là.
2) même problématique pour l'autre table.
Sans compter les redondances que vous évoquez vous-même.
3) si les *valeurs* de vos paramètres sont discrètes et peu
nombreuses il peut être intéressant de les stocker dans une table
à part et de faire des jointures. Mais cela dépend vraiment des
valeurs (entier ? chaînes de caractères ? etc.) et de l'usage.
Maintenant pour la modélisation, si j'ai bien compris votre
problème (pas sûr, parce que param3 et param4 je ne sais pas ce
que c'est), c'est un cas classique de table mise à jour dont vous
souhaitez conserver les mises à jour.
Il y a en gros deux pistes, chacune avec des avantages et
inconvénients.
A) soit une table d'archivage identique à la table archivée avec
un attribut supplémentaire indiquant quand l'archivage a eu lieu
donc pour vous ca serait en gros (à modifier selon mes dires plus
...
A noter que l'insertion avant le UPDATE peut être faite
automatiquement via une procédure stockée et un déclencheur dans
le SGBD.
B) soit on veut éviter encore plus les redondances, et donc on ne
va archiver que ce qui change.
C'est un peu plus compliqué à mettre en oeuvre, on peut
éventuellement toujours s'en sortir avec un déclencheur, mais en
général on fait ca du coté applicatif
...
L'option B continue de fonctionner même si boitier change de
schéma, alors que dans l'option A il faudra aussi changer le
schéma de boitier_archive (ce qu'on va typiquement oublier de
faire, d'où problèmes après).
Maintenant si vous rassemblez tout cela et que vous souhaitez
gérer un nombre quelconque (dans le temps et l'espace) de
paramètres pour vos boitiers, une seule et même table peut faire
l'affaire (ou non).
boitier (id,nom,param_name,param_value,communication_date)
Si une même communication met à jour plusieurs boitiers, vous
pourriez avoir une table communication avec un id et une date, et
au lieu d'avoir l'attribut date dans boitier cela serait une
référence à l'id de la table communication.
Pour un boitier donné, la configuration actuelle correspond aux
tuples (la ligne) avec la valeur communication_date la plus
élevée. Et vous pouvez gérer autant de paramètres différents que
vous souhaitez : chaque paramètre est dans un seul tuple.
...
Il faut après adapter un peu la logique, ou se baser sur les
fonctionalités de partitions du SGBDR, ou écrire des déclencheurs
pour : 1) créer automatiquement les tables en fonction des besoins
(dès qu'on entre dans un nouveau mois)
2) faire les insertions dans la bonne table
3) selon les sélections, faire des unions
Après réflexion sur le schéma il faut le tester, pour les
performances, il est difficile de les deviner, cela dépend
...
J'espère vous avoir donné quelques pistes de réflexion.
BTW, tout ce qui précède n'a rien de spécifique à MySQL. Ma
réponse est généraliste, et en terme de SGBDR je pense qu'il vaut
mieux essayer de ne pas penser en terme d'un seul moteur. Cela
donne trop de problèmes après sinon.