Discussion :

[izioto]

bonjour,

je dois concevoir une base de donnée permettant le stockage de points de mesure qui seront ensuite utilisés pour générer des graphiques de suivi de production.

A la sortie d'une ligne de production, un robot effectue des mesures pour vérifier la conformité des pièces produites.
Les mesures se font en 3, 10 ou 15 points différents suivant le modèle de la pièce fabriquée.

La production est d'environ 1000 pièces par jour, et donc :
- au minimum : 3000 points de mesure par jour,
- au maximum : 15 000 points de mesure par jour.
(=> c'est selon les plannings de production).

La consultation en base doit pouvoir se faire sur les 3 derniers mois (delete des mesures > 3 mois par batch toutes les nuits), donc :
- au minimum : 270 000 points (3000 x 30 x 3)
- au maximum : 1 350 000 points (15 000 x 30 x 3).

Quel est le meilleurs modèle pour cela ?

Une seule table :
MESURE (id_mesure, date, type_piece, pm1, pm2, pm3 ... pm14, pm15)

Ou deux tables :
MESURE (id_mesure, date, type_piece)
POINTS (id_point, id_mesure, position, valeur)

Je pense que c'est la seconde car elle correspond plus a une modélisation sous forme de relation, et de plus, si 1 mesure ne comporte que 3 points on ne stocke pas 12 valeurs 'null'.

Mais en terme de performance, quelle est la meilleurs solution ?
En terme d'espace de stockage disque ? (par ex : 1ere solution => 1 seul index, 2eme solutions => 2 index, voir 3 index)

La jointure a faire entre les deux tables ne risque t-elle pas de ralentir les perfs ? Ou peut être est-ce finallement la même chose ?

Pour info le SGBD n'est pas encore "choisi" :
- ORACLE,
- MS SQL server,
- ou MySQL.

(sachant que les deux 1er sont déjà utilisé dans la maison mais que le département pour qui je travaille préférerait la mise en place d'un serveur bdd qui lui serait dédié => MySQL ).

Merci de votre aide.


izioto

[qi130]

Sans hésiter: le modèle à 2 tables !

Tu pourras aussi bénéficier d'un ON DELETE CASCADE lors de l'épuration.

[izioto]

Sans hésiter: le modèle à 2 tables !

Merci qi130, mais pourrais tu argumenter ton avis ?
Pour quelles raisons est ce le meilleur modèle ?
Je suis d'accord pour dire que c'est celui qui est le plus normalisé, mais quels sont réellement les avantages du second modèle par rapport au premier : est ce en terme de perf, de maintenance, etc... ?

Car ce qui m'inquiete dans le second modéle c'est la volumétrie !

Car supposons que je sois dans la configuration ou mon historique est au max (3 mois) et que le planning de production ait été tout le temps de la production de pièces à 15 points de mesure.

Une seule table :
La table MESURE aurait 1 350 000 enregistrements (15 000 x 30 x 3) avec 18 colonnes.

Avec deux tables :
La table MESURE aurait 1 350 000 enregistrements (15 000 x 30 x 3) avec 3 colonnes.
mais la table POINTS en aurait 20 250 000 enregistrements (1 350 000 x 15) avec 4 colonnes.

Gloups, non ?!

Y a t-il d'autres avis, points de vue ?

Merci.

izioto

[izioto]

Personne m'a d'avis sur la question ?

20 250 000 enregistrements est-ce bcp pour une table ?

Merci

izioto

[SQLpro]

Encore une fois ce n'est pas le nombre de ligne qui est important, c'est le volume des données manipulées. Dans tous les cas il me parait invraisemblables que caque requête de lecture porte sur 25 millions de lignes...

Donc, faire un calcul précis avec le nombre moyen de lignes par mois du volume des données, sachant que INTEGEER et DATE c'est 4 octets, FLOAT 8 et qu'il faut rajouter le volume des index.

A +