Discussion :

[rvzip64]

Salut tout le monde,

J'ai actuellement une base de données normalisée.
Elle est prévue pour recevoir des mesures de plusieurs équipements.
Un équipement est prévue pour faire des centaines mesures sur des milliers d'entités.

J'ai donc une table de mesure par équipement (les équipements étant tous différents, ils ne renvoient pas forcement les mêmes types de mesure).

Chaque table à donc la forme suivante:

Pour l'équipement A

Entity Id
Mesure A
Mesure B
Mesure C


Pour l'équipement B

Entity Id
Mesure A
Mesure D
Mesure G


Maintenant je dois faire des statistiques sur ces tables, et je suis "embêté" car je dois écrire une requête par table alors, que je fais toujours le même calcul derrière....
Je demande donc si je ne devrais pas plutot faire une seule table pour tous les équipements du style :

Equipment Id
Entity Id
Mesure Id
Value

Vous en pensez quoi ?

Cordialement

[Richard_35]

Bonjour Rvzip64,

Equipment Id
Entity Id
Mesure Id
Value

Vous en pensez quoi ?

==> auto-réponse éclairée d'un membre éclairé.

[rvzip64]

Donc on est d'accord que cela va prendre beaucoup plus d'espace au niveau des index que la première méthode, mais que ce n'est pas grave ?
Ce que je vais "perdre", je vais le gagner en facilité de développement et d'évolutivité

[Richard_35]

... cela va prendre beaucoup plus d'espace au niveau des index que la première méthode...

==> eh bien, non :

• méthode actuelle : 1 index par équipement ;
• nouvelle méthode : 1 seul index unique (identifiant) sur le triplé Equipment Id/Entity Id/Mesure Id.

mais, peu importe.

Ce que je vais "perdre", je vais le gagner en facilité de développement et d'évolutivité

==> ça, en revanche, c'est certain !...
D'autant que, conceptuellement, la nouvelle méthode est la bonne : créer plusieurs entités (conceptuel) pour un même type d'objet (réel) n'est jamais très bon.

[rvzip64]

Aller dernière petite question ...

Vu que j'ai plusieurs "Mesure Id", je peux avoir des types différents entre les "Mesure Id" : Double; Int; ...
Comment je peux faire vu que je n'ai qu'un seul champ "Value" ?

[Richard_35]

Tu ne peux pas définir ton champ Value en "réel double" ?
Qui peut le plus peut le moins...

[Miistik]

Bonjour,

Petite remarque (peut-être stupide) :
D'où vient ton idée de faire une table de mesure par équipement ?

En général, le choix de la création d'une table vient d'un MCD-MPD.

[rvzip64]

On va dire que c'est une question d'historique ...
Et que à l'époque ça a simplifié certaine tâche de développement en isolant les équipes de dev...

Avec l'expérience on voit que ce n'est pas forcément adapté

[Miistik]

Lorsque tu dis :

Equipment Id
Entity Id
Mesure Id
Value

Ce sont des noms de colonnes ?

[rvzip64]

Exact

[Miistik]

Bonjour,

Si on suit ton idée :

Equipment Id
Entity Id
Mesure Id
Value

Il risque d'y avoir des enregistrements où seuls l'id de mesure et la value changeront.
Il pourrait être logique de faire deux tables : une avec les equipements et entités et l'autre avec les mesures et valeurs accompagnés de equipment id et entity id en clé étrangère.
Je ne suis pas admin BDD donc à confirmer.

Mais en soit ta proposition semble alléger quand même grandement le système actuel.

Tout dépend de ta marge de manoeuvre sur ce sujet.
Si tu as la possibilité, refais un MCD et une base etc ...
Sinon une évolution comme tu le proposes aura son petit impact positif.

A voir si cela ne perturbes un autre service ou le fonctionnement d'autre chose.

[rvzip64]

Je suis d’accord avec toi Miistik, il faut optimiser le principe.
Le point le plus important pour moi était d'avoir votre avis sur un stockage par ligne plutôt qu'un stockage par colonne.

J'ai une grande marge de manœuvre sur le système, j'ai lancé la conversation d'une table hier soir.
Je vais maintenant lancer des tests pour voir l'impact que cela peut avoir au niveau du système.

Je laisse le post ouvert, je vois déjà des petits problèmes qui vont arriver

[rvzip64]

Finalement, c'est le principe des métadonnées
http://sqlpro.developpez.com/cours/m...n/metadonnees/

Quelqu'un à déjà fait mis en place un système de métadonnées en suivant le principe de sqlpro ?

[Drizzt [Drone38]]

Le système exposé par SQLPro, c'est surtout si tu veux pouvoir ajouter dynamiquement par la suite des nouveaux type de mesures.

Mettre des types de mesures différents dans une même colonne ça peut être pratique, mais tu peux perdre en intégrité des données. En effet tu ne pourras pas garantir que tes données de type A sont bien de type Int et tes données de type B de type Double (Via contraintes et/ou trigger tu pourrais, mais ça impactera des perfs en insertion).

En toute logique donc tu devras faire de la conversion de données dans tous les sens. Surtout si tu commences à avoir des types de mesures en format texte.

La question à se poser est donc sur l'utilisation de tes données. Quel est le besoin, quelles sont les requêtes que tu devras faire ?
Si tu travailles tout le temps par Type d'Equipement, mettre tout dans une même table n'est pas forcément judicieux.

Après si tu laisses sur plusieurs tables séparées, tu peux utiliser des vues qui regroupent tes données pour faciliter les quelques requêtes transverses aux équipements.

[rvzip64]

C'est certain qu'avec les méta données je vais avoir pas mal de cast et que cela va prendre du temps !
D'ailleurs je me demande s'il n'était pas possible de faire un cast "automatique", vu que dans une table il y a le type qui est stocké ... mais aucune idée de comment on pourrait faire ça