Discussion :

[persia]

Bonjour,

J'ai 5 tables qui ont la même structure soit : id, nom, description. Donc j'aimerais savoir c'est quoi la meilleure conception ou façon de faire pour éviter d'avoir 5 tables qui auront les mêmes colonnes :

1 - Je crée une table catégorie qui va inclure mes 3 colonnes communes et une autre colonne "enum" qui va différencier mes catégory : ex (Ville, Pays, Continent, etc)
2 - Créer une table catégorie qui va inclure mes 3 colonnes communes et créer les autres 5 tables qui vont juste inclure un id.

Note que j'aurais une table d'assocation qui doit avoir les id des villes, pays, continents, etc pour les afficher ensuite dans un rapport

Merci de votre conseil.

[escartefigue]

Regardez plutôt le partitionnement, une seule table, plusieurs partitions en fonction d'un critère que vous définissez et qui peut être modifié dans le temps si besoin

Si en plus votre table contient des volumes importants ou très importants (milliards de lignes et au delà) c'est LA solution

[SQLpro]

En matière de modèle de données, l'héritage est la bonne solution. Le partitionnement n'est pas une solution de modélisation, mais une solution de stockage et donc du ressort du DBA, pas du concepteur (structure logique) de la base. Le partitionnement pourra avoir lieu en toute indépendance des structures logiques, par rapport à la volumétrie des données et cela ultérieurement, au bon moment, quand cela apparaîtra nécessaire....

Sur l'héritage, lisez les papiers que j'ai écrit : http://sqlpro.developpez.com/cours/m...tion/heritage/


A +

[escartefigue]

En matière de modèle de données, l'héritage est la bonne solution. Le partitionnement n'est pas une solution de modélisation, mais une solution de stockage et donc du ressort du DBA, pas du concepteur

Je suis tout à fait d'accord, mais

J'ai 5 tables qui ont la même structure soit : id, nom, description. Donc j'aimerais savoir c'est quoi la meilleure conception ou façon de faire pour éviter d'avoir 5 tables qui auront les mêmes colonnes

On est déjà au niveau tables, donc plus au niveau conceptuel, et quand bien même, vu que les 5 tables sont 100% identiques, on est typiquement dans le cas d'utilisation d'une table partitionnée, et non au niveau héritage qui lui s'applique quand une partie seulement des colonnes est commune.
La seule chose à savoir c'est : y a-t- il une clef candidate pour le critère de partitionnement, ça ne semble pas évident avec seulement id, nom, description

[SQLpro]

Le partitionnement suppose de connaitre le SGBDR cible. Cela n'est pas la demande ! La demande porte sur articulation des tables et c'est bien d'un modèle dont on parle. Certaines personnes modélisent directement au niveau physique ce qui est une mauvaise pratique, mais cela est nullement interdit !

Il existe des SGBDR qui ne supportent pas le partitionnement (Access, SQL lite... entre autres), il y en a qui disent le faire, mais c'est de la merde (MySQL, PostgReSQL) et il y en a d'autres qui le font royalement (DB2, Oracle, SQL Server)....

A +

[escartefigue]

Si l'on est encore au niveau modélisation, alors il est assez probable que les différents contenus (villes, pays, continents, etc..) possèdent à terme des attributs différents
auquel cas vous pouvez modéliser soit une entité type par type de contenu, soit une entité type pour ce qui est commun et un sous type pour ce qui est spécifique à chaque contenu

Si l'on est déjà au niveau physique et que les 5 utilisations utilisent et utiliseront à terme les mêmes colonnes, alors je maintiens, sous réserve effectivement que votre SGBD le gère, que le partitionnement vous simplifiera la vie à tout point de vue. Utilisez la colonne enum comme critère de partitionnement.

Quel est votre SGBD ? est il déjà installé ? votre table (ou vos 5 tables) est elle une évolution d'une application existante ?