Discussion :

[jax54000]

Bonjour,

Je débute en BD.

Je me pose une question simple : est-il préférable de découper/diviser les tables le plus possible ? Exemple :

2 tables :
- Produit type A
- Produit type B
Déjà là : mieux vaut-t-il créer 2 tables (A et B) ou mieux vaut-il en avoir une seule avec un champ type ?

Imaginons ensuite que chaque type de produit soit lié à un document de spécification. Mieux vaut-il créer une table "Specification" unique avec un champ "type" ou mieux vaut-il en créer 2 : "Spécification A" et "Specification B" ?

En fait je suis en train d'essayer de créer ma base de données mais je trouve que j'ai déjà beaucoup de tables, environ 22, sachant que ça devrait monter, si je continue comme ça, à environ 40 (je suis parti sur la solution : diviser autant que possible les tables)

Merci.

A+

[CinePhil]

Il vaut mieux une table de stypes et une relation entre les produits et les types.
Le MCD suivant :
Produit -1,1----Typer----0,n- Type

Donne les tables :
Type (T_Id, T_Libelle)
Produit (P_Id, P_IdType, ...)

[Vincent Rogier]

la réponse n'est pas si simple... et dépend du type de données (liste attributs distincts, du volume stocké et du traitement effectué sut les données (sélection, dml massif, computation, etc..)

Dans le cas d'objets relativement simples, peu discordants, avec un faible volume de stockage et peu de traitement, la solution donnée précédemment s'applique.

mais dans le cas de gros volumes avec des requêtes complexe (grosses jointures, redondance des données, utilisation de fonctions analytiques et voir appels langage procédural serveur) et fréquentes, il peut être préférable de gérer plusieurs tables distinctes...

Tout dépend donc de l'utilisation des données...

[jax54000]

Merci à vous 2.

Je pense donc qu'il vaut mieux anticiper et créer plusieurs tables (les diviser).

Pas facile mais je pense que je vais partir sur cette solution.

A+

[Vincent Rogier]

attend, faut pas de presser sur un modele ! Faut bien y réflechir...

Si tes objets sont peu différenciés et que la disparité est limité à quelques dizaine, vaut peut être mieux la 1ere solution
Quand je parle de gros volume, je parle de millions d'items composant un réfentiel.
Quand je parle de grosse requête, je parle pas de 2 jointures sur un dml simple !
Quand je parle de traitement complexe, je fais référence à de l'analytique, utilisation de PL/SQL par exemple pour Oracle, computation avec sous interrogation, etc...

[CinePhil]

mais dans le cas de gros volumes avec des requêtes complexe (grosses jointures,

Même avec de grosses tables et des jointures multiples, une base de données normalisée et bien indexée sur un serveur correctement dimensionné ne doit pas avoir peur des "grosses jointures" et répondre en un temps satisfaisant.

redondance des données,

Ca ne doit carrément pas exister dans un SGBDR, sauf base de données répartie sur plusieurs sites.

Commence par modéliser correctement tes données.
Implante fidèlement le modèle.
Alimente le en données.
Si il y a des requêtes trop longues, reviens nous voir avec des exemples pour qu'on t'aide à résoudre le problème.
La dénormlisation ne doit venir qu'en dernier ressort.

[fsmrel]

la réponse n'est pas si simple... et dépend du type de données (liste attributs distincts, du volume stocké et du traitement effectué sut les données (sélection, dml massif, computation, etc..)

Dans le cas d'objets relativement simples, peu discordants, avec un faible volume de stockage et peu de traitement, la solution donnée précédemment s'applique.

mais dans le cas de gros volumes avec des requêtes complexe (grosses jointures, redondance des données, utilisation de fonctions analytiques et voir appels langage procédural serveur) et fréquentes, il peut être préférable de gérer plusieurs tables distinctes...

Tout dépend donc de l'utilisation des données...

Votre approche n’est pas la bonne, vous mélangez tout. Quand on modélise les données, on ne s’intéresse ni à la volumétrie des données ni à la nature des traitements. On s’intéresse au quoi, mais ni au quand, ni au comment, ni au où. C’est la base du métier. Ceci vaut pour le niveau conceptuel et pour le niveau suivant, à savoir le niveau logique.

C’est dans une phase ultérieure que l’on agira au niveau physique pour que les traitements soient performants, à coups d’index, de partitionnement et autres regroupement des données. Pour faire court, on construira un prototype pour tester la performance des requêtes qui seront hébergées par les quelques transactions a priori les plus sensibles : prise de commandes par exemple (même principe pour les batchs). Mais si elle a été menée dans les règles de l’art, la modélisation conceptuelle (et par contrecoup la modélisation logique) n’a pas à être impactée.

Si donc, pour reprendre la solution proposée par CinePhil, on a N produits ressortissant chacun à un type de produit, sa modélisation n'est pas à remettre en cause, que l’on ait 10 produits et 3 types de produits, ou 100000 produits et 1000 types de produits. Le principe reste valable pour des tables qui contiendraient 500000000 de lignes.

[jax54000]

Merci.

Intéressant de vous lire.

Je modélise ma base avec Toad Data Modeler. Mais peut-être suis-je déjà dans le modèle physique...

Un idée de ce que je suis en train de créer : http://www.cijoint.fr/cj200911/cijIItKCng.jpg

Pour comprendre un peu : tout ce diagramme n'est destiné qu'à un produit (TWT).
Comme je suis parti, je vais devoir créer une duplication de ce diagramme pour un 2ème type de produit - TWTA (Je n'aurai au total que 2 types de produits.)
Donc à savoir que par exemple la table MIP ou TRB data ou encore EIDP et d'autres seront constituées exactement des même champs.

Je sais que ça ne doit pas être facile à dire à première vue mais pensez-vous à vue de nez que je devrais mettre ces tables en commun ?

Merci.

A+