Discussion :

[blacksad1234]

Bonjour,

J'ai un doute sur comment structurer les tables de ma base de données, et je pense que c'est un problème relativement fréquent mais je ne suis pas parvenu à trouver un tuto ou un "guide de bonnes pratiques" à ce sujet.

J'ai d'un côté des tables décrivant des objets physiques (des équipements, des accessoires, des cylindres, etc.) et de l'autre côté, des lieux (chez le fournisseur, dans un laboratoire, dans une station, sur un site mobile, etc.)

Les objets physiques ont des caractéristiques suffisamment différentes pour que la question de leur factorisation ne se pose pas : ils ont chacun leur table.

Par contre, les lieux ont beaucoup en commun (coordonnées GPS, altitude, adresse, numéros de téléphone). Ils ont également certaines différences, soit dans les colonnes (j'ai besoin de définir un champ "code d'accès" pour les stations mais pas pour les autres lieux, par exemple), soit par les relations qu'ils ont avec les objets physiques (expl : un cylindre peut aller partout, sauf chez un fournisseur).
De plus, je veux tracer les positions successives de mes objets, donc il me faut une table de liaison entre un objet et le lieux pour stocker la date d'entrée et de sortie d'un objet dans un lieux.


La question est donc : quelle est la meilleur méthode pour gérer ça ?

1. Factoriser : je crée une table "Lieux" plus ou moins générique, qui contient les champs communs à tous les lieux.
Je crée des tables fournisseur, laboratoire, station, etc. qui auront pour clé étrangère le Lieux qui correspond.
Tous mes objets physiques sont "branchés" sur la table Lieux.
Si je veux avoir des informations complètes sur un lieu particulier, je recompose mon lieux à partir des informations de ma table Lieux et de la table spécifique qui correspond (Fournisseur, Laboratoire, etc.).
Dans ma table "Lieux", j'ajoute un champ ENUM('fournisseur', 'laboratoire', ...) pour faciliter les requêtes : vu que je sais quel type de lieu c'est, je peux aller piocher directement dans la bonne table sans devoir tous les parcourir, à la recherche de celle qui contient la clé étrangère qui m'intéresse.

2. Une table par lieu.
Il faut dupliquer les colonnes communes et multiplier les tables de liaisons (s'il y a "n" types de lieux et "m" types d'objets, il y aura n*m tables de liaisons avec la solution 2 alors qu'il n'y en aura que "m" avec la solution 1)


Qu'en pensez-vous ?
Du point de vue de la base de données, la solution 1 semble la meilleure, mais du point de vu de l'application, la 2 semble la plus simple, il n'y a pas besoin de courir après les tables spécifiques de lieux pour savoir à quoi correspond le Lieux ; on n'a plus cette "coquille vide" (ou abstraite) qu'est la table "Lieux".

Quelle est la bonne pratique dans ce cas ?
Merci !

[tatayo]

Bonjour,

Les objets physiques ont des caractéristiques suffisamment différentes pour que la question de leur factorisation ne se pose pas : ils ont chacun leur table.

Je ne suis pas d'accord. On peut n'utiliser que 5 tables ici, quelque soit le nombre d'objets physiques:
1. Type D'objet, avec un Id et un Nom
2. Caractéristique: Id, Nom
3. Une table croisée entre ces deux tables, qui fait le lien entre un type d'objet et une caractéristique
4. Objet, avec son Id, L'id de son type (clé étrangère)
5. Caractéristique d'un objet, avec son Id, L'id de l'objet (FK), l'Id de la caractéristique (FK) et sa valeur

Ainsi on peut créer autant d'objet que nécessaire, autant de type d'objet que nécessaire, avec autant de caractéristiques que nécessaire, sans toucher au schéma.

Idem pour les lieux.

Tatayo.

[punkoff]

bonjour,


vous aurez surement plus de réponse dans ce forum :
http://www.developpez.net/forums/f62...sation/schema/

Un article parmi d'autre sur l'héritage : http://sqlpro.developpez.com/cours/m...tion/heritage/


Je penses qu'il faudrait que vous preniez un peu plus de temps pour modéliser la partie objet.


Surtout quand je lis ça :

De plus, je veux tracer les positions successives de mes objets, donc il me faut une table de liaison entre un objet et le lieux pour stocker la date d'entrée et de sortie d'un objet dans un lieux.

En "factorisant" votre entité objet on arrive à une relation du type
Objet-0,n-------Passe---------0,n-Lieu

Pas besoin de dupliquer m ou n*m fois cette relation, comme avec votre modélisation actuelle.

(sinon je préfère aussi l'approche héritage pour les lieux, une fois les vues / triggers implémentées son utilisation lors du développement sera presque triviale)

[blacksad1234]

Merci pour vos réponses (très !) rapides et complètes.

Pour la factorisation de objets, dans mon cas je ne pense pas que ce soit adapté. Je n'ai pas beaucoup de types d'objets différents (4 plus un objet qui est plutôt une "collection d'objets") et ils n'ont quasiment aucune caractéristique en commun.

@tatayo : j'avais déjà croisé cette structure qui met les caractéristiques dans une table séparée sous la forme (id, nom de la caractéristique, valeur de la caractéristique). J'avoue que je ne suis pas assez calé et familier avec le php, le SQL et MySQL, ce n'est pas assez intuitif pour moi Et comme dit plus haut, il me semble que dans mon cas perso, le jeu n'en vaut pas la chandelle.

L'article sur l'héritage est intéressant, les exemples ressemblent pas mal à mon cas. Je ne connaissait pas les view, ça m'a l'air bien pratique pour rendre transparent le découpage en tables mère-fille et simplifier la partie applicative.

Bon ben yapluka s'y mettre sérieusement et voir comment ça se met en pratique !


(Et effectivement, il semblerait que ce topic ne soit pas dans la bonne catégorie, j'ai pas l'impression que je puisse le déplacer moi-même, si un modo passe par là...)

[pacmann]

Je ne suis pas d'accord.

Et moi je ne suis pas d'accord avec toi, Tatayo. Transformer ta base de données en clef / valeur, ça résout effectivement tout.
Par contre, derrière, l'écriture d'un bon nombre de requêtes devient monstrueuse... sans te parler des problèmes de perf qui vont avec.

L'héritage, comme le dit Punkoff, est la bonne solution. Il faut identifier les types d'objets (grandes catégories), puis en faire des tables.

EDIT : pour donner un exemple, là où comparer deux lignes dans un modèle "normal" revient en gros à faire une jointure, dans un modèle clef / valeur, ça devient tout de suite une espèce de division relationnelle. Et personne n'a envie de passer son temps à faire des divisions relationnelles...

[tatayo]

J'avoue humblement que je ne connaissait pas l'héritage de table, Maxdb ne proposant pas cette fonction (en tout cas dans la version que j'utilise).
Vu que dans un avenir (plus ou moins) proche nous allons migrer sur SqlServeur, je vais me pencher sur cette fonctionnalité.

Tatayo.

[pacmann]

Ben ce n'est pas vraiment une question de fonctionnalité, mais plus de modélisation.

Regarde un peu le lien de Punkoff vers le tuto SQLPRO : tu vois qu'il s'agit vraiment de factorisation, avec une table "maître" (par exemple personne) qui décrit ce qu'est une personne, et toutes les tables autres tables décrivant des personnes de type particulier (prospect, employé et client) qui référencent cette table.