Discussion :

[brouis]

Bonjour,
je vous expose rapidement ma problématique, j'ai conçu une Bdd d'une application client / serveur pour un bureau d'étude. Cette application permet tout simplement de réaliser des prestations sur des équipements (différents type d'audit). un audit est une série de questions auquel l'auditeur réalise des mesures ou répond aux questions en sélectionnant une réponse dans une liste.
Vous trouverez ci-joint le schéma de ma Bdd.

une autre précision : l'application permet de créer la volée des nouveaux types de prestations, de nouvelles questions, ETc tout est paramétrable...
un audit comporte en moyenne 230 questions. toutes les réponses sont stockées dans la table Valoriser ==> elle est énorme aujourd'hui (presque un million de lignes)

Ma problématique : nous souhaitons ajouter un nouveau type de prestations qui garde la même logique mais avec un traitement un peu différent et bien sur le but final est toujours garder les relations entre différentes prestations effectuées sur un seul équipement ==> garder la dernière mesure connue.

pour répondre à cette problématique : un collègue propose de dupliquer toutes les tables (copier/coller des tables existantes pour séparer les deux prestations).
je ne suis pas d'accord avec sa proposition pour la simple raison que c'est complètement inutile et ça ajoute du travail pour rien. à la limite dupliquer la table Valoriser (table qui évolue a raison de 230 ligne a chaque nouvelle prestations), je veux bien mais les autres ça n'a aucun intérêt a part créer des tables en doubles dans la Bdd ??

Je pars du principe de factoriser des Bdd et non les dupliquer.

quelle solution pensez vous est plus intéressante ?
Merci de vos réponses

[elsuket]

Bonjour,

Votre approche est de toute façon la meilleure : en bases de données relationnelles SQL, on ne duplique pas, ou alors la conception a été mal faite.
Or, au vu de votre modèle physique, ça m'a plutôt l'air réfléchi.

Ma problématique : nous souhaitons ajouter un nouveau type de prestations qui garde la même logique mais avec un traitement un peu différent et bien sur le but final est toujours garder les relations entre différentes prestations effectuées sur un seul équipement ==> garder la dernière mesure connue.

Dommage que vous n'ayez pas donné plus de détails, aussi il est probable que cela ne vous soit pas possible.
Rien n'empêche l'ajout de nouvelles tables pour supporter le nouveau type de prestation.

Il serait donc judicieux d'ajouter un type de prestations, étant donné que si vous partez sur deux types de prestations, il est fort probable que dans le futur la base de données doive en supporter bien plus.
De là vous ajoutez une colonne dans la table prestation, qui indique le type de la prestation.

Vous pouvez aussi procéder par héritage, c'est à dire :
- une entité comprenant tous les attributs communs à toute prestation
- chaque prestation s'exclut de toutes les autres, référence l'entité mère décrite ci-dessus, et ne contient que les attributs qui lui sont spécifiques.

Par exemple, un entité mère prestation, et des entité filles "audit", QCM, sur site, ...

Malheureusement sans plus de détails, difficile d'aller plus avant

@++

[brouis]

Bonjour,

Il serait donc judicieux d'ajouter un type de prestations, étant donné que si vous partez sur deux types de prestations, il est fort probable que dans le futur la base de données doive en supporter bien plus.
De là vous ajoutez une colonne dans la table prestation, qui indique le type de la prestation.

@++

ma table prestation contient toutes les informations administratives de la prestation : date de saisie, adresse, IdEquipement, IdClient, IdAuditeur,Etat, Type prestation.

Selon le type de la prestation je charge la liste des champs (questions) affecté à un audit.

jusqu’à la mon modèle de Bdd peut supporter n type de prestations ainsi que n champs de saisie.

la faille de mon modèle de données ( à mon avis) réside dans la table valoriser qui se remplit trop vite.

Ma problématique est que la deuxième personne qui bosse avec moi sur le même projet ne résous pas vraiment le problème vu qu'il a dupliquer mon modèle pour un nouveau type de prestation ==> donc un jour ou l'autre la table valoriser de la nouveau type de prestation arrivera à son tour à devenir énorme et se retrouvera confronté à la même problématique.

[elsuket]

la faille de mon modèle de données ( à mon avis) réside dans la table valoriser qui se remplit trop vite.

C'est-à-dire ? Combien de lignes enregistrez-vous par jour ?
Ou quand vous modifiez (entendez par là INSERT + UPDATE + DELETE) la table, combien de lignes affectez-vous ?
Vous pouvez envisager le partitionnement ...
Quel est le mode de restauration de votre base de données ?

Ma problématique est que la deuxième personne qui bosse avec moi sur le même projet ne résous pas vraiment le problème vu qu'il a dupliquer mon modèle pour un nouveau type de prestation ==> donc un jour ou l'autre la table valoriser de la nouveau type de prestation arrivera à son tour à devenir énorme et se retrouvera confronté à la même problématique.

Effectivement c'est totalement absurde.
Je vous suggère vivement d'avoir une discussion là-dessus avec lui/elle.
Si cela ne suffit pas, et en supposant que votre supérieur sache ce que signifie bases de données relationnelle SQL, ce qui, entre nous, est rarement le cas, voyez avec eux.

Dans ces cas-là, moi quand j'en ai assez, je donne ma démission ...

@++

[brouis]

C'est-à-dire ? Combien de lignes enregistrez-vous par jour ?
Ou quand vous modifiez (entendez par là INSERT + UPDATE + DELETE) la table, combien de lignes affectez-vous ?
Vous pouvez envisager le partitionnement ...
Quel est le mode de restauration de votre base de données ?

@++

alors nous avons 40 consultants qui saisissent en moyenne 4 audit par jour et par personne donc (230 lignes * 40 * 4 ) par jour.
mode d'insertion :
une ligne dans la table Prestations et 230 lignes dans la table Valoriser.
les requêtes sont uniquement des INSERT parce que même en mode modification : on supprime et on réinsère.
notre Bdd est totalement hébergé et on s'occupe pas de la restauration. je sais qu'elle est mode cluster mais le reste je ne l'ai jamais géré
Merci de votre aide

[elsuket]

Bon alors ça fait 36.800 lignes par jour, rien de bien méchant.
Pensez simplement à bien indexer et éventuellement à partitionner par année, car cela fait 13 millions de lignes environ

En revanche, évitez à tout prix la duplication.

@++

[brouis]

Bon alors ça fait 36.800 lignes par jour, rien de bien méchant.
Pensez simplement à bien indexer et éventuellement à partitionner par année, car cela fait 13 millions de lignes environ

En revanche, évitez à tout prix la duplication.

@++

Merci pour le conseil ça me rassure.
En revanche, quand vous dites "partitionner par année" : je n'ai aucune idée comment je pourrais gérer ça . est ce que je pourrais faire une table Valoriser2010, une table Valoriser2011 et ainsi de suite ?
Après si dois chercher sur toute la Bdd, j'utilise les union ?

Ensuite, concernant les index, normalement, la table est indexé. j'ai ajouté une capture d'écran.

Merci encore

[Jinroh77]

le partitionnement consiste à découper une table techniquement sans en changer son aspect fonctionnel.
Vous aurez donc toujours 1 seule table "Valoriser" mais celle-ci sera découpée en plusieurs selon une fonction de partitionnement.
L'idée est alors de répartir ensuite les différentes parties sur des disques durs différents.
Un peu de lecture (SQL 2005).

[elsuket]

La réponse de Jinroh77 est tout à fait exacte.

En ce qui concerne l'indexation, il semble que vous n'ayez que l'index de clé primaire.
En effet par défaut, lorsqu'on crée une clé primaire, un index cluster est créé sur la table.
Mais rien ne vous empêche d'ajouter des index non-cluster pour aider la recherche de lignes vérifiant les prédicats de jointure et de filtrage sur cette même table.

Veillez à ne pas mettre les colonnes qui participent à la clé de l'index cluster dans les index non-cluster : l'index non-cluster référence les lignes de l'index cluster (comme l'index à la fin d'un livre référence un numéro de page, qui est l'index cluster du livre : c'est l'ordre physique des pages).

Si vous en venez à partitionner, veillez à aligner vos index sur le schéma de partitionnement de la table.

Pour en savoir plus sur le partitionnement de tables, je vous invite à lire un peu ici et ici.

@++

[brouis]

Merci pour tout.