Bonjour à tous les Zéros

J'ai été employé dans une boîte qui analyse la publicité des magazines papier.

Après avoir effectué un BTS Informatique de Gestion option Développeur d'Applications, et donc fait un peu d'analyse, j'ai des questions concernant leur base.

La première question concerne la quantité de champs dans une table. En moyenne, je dirais 25 champs, et avec un maximum d'environ une cinquantaine.

Prennons par exemple les visuels contenus dans un numéro.
Un numéro peut avoir plusieurs visuels, de même un visuel peut apparaître dans plusieurs numéros, on a une table (que l'on nomera visuels_numéros) qui fait la liaison entre la table visuels et la table numéros.

En voici le MCD :


En toute logique, la table visuels_numéros ne devrait contenir que les id des tables visuels et numéros, voir même une clé primaire pour cette table. Mais dans mon cas, j'ai beaucoup de champs qui sont identiques aux champs de la table visuels dans la table numéros_visuels.



Cette question en entraîne une plus générale,



Ce que j'avais compri de mes cours est qu'il vaut mieux multiplier les table. On m'a toujours dit :

Citation

si t'as un doute, fais une table!!!

Mais ceci dans le but d'améliorer la compréhension du modèle.


Je me pose ces questions en réalité car je dois réaliser des sites web, et que la réactivité doit en être bonne. Or pour l'instant, c'est très aléatoire.

Merci d'avance pour vos réponses.

Citation : Spirit_3w6

La première question concerne la quantité de champs dans une table. En moyenne, je dirais 25 champs, et avec un maximum d'environ une cinquantaine.

pour le nombre de champs par table : il n'y a pas de maximum ... a partir d'un moment ce sera une question de "relation" ( quand je veux charger cet info, ai-je réellement besoin des 40 champs associées ou juste de 5-6 ? => si la réponses est "a priori 5-6 sont suffisant" : la relation 1-1 est la bien venue)

Citation : Spirit_3w6

En voici le MCD :

Le MCD est effectivement la structure la plus logique !

Citation : Spirit_3w6

En toute logique, la table visuels_numéros ne devrait contenir que les id des tables visuels et numéros, voir même une clé primaire pour cette table. Mais dans mon cas, j'ai beaucoup de champs qui sont identiques aux champs de la table visuels dans la table numéros_visuels.

pour ta table de liaison : 2 questions :
- le couple Numéro.id et Visuel.id sera-t-il unique ? ( d'après ce que tu explique : oui )
- hormis les champs Numéro.id et Visuel.id tu compte "stocker" quoi dans cette table ? , est-ce que les champs "commun" avec la table Visuel vont avoir des "valeur différentes" pour 1 Visuel.id donné ?

Citation : Spirit_3w6

N'est-ce pas mauvais pour la réactivité de la base d'avoir beaucoup de champs dans cette table numéros_visuels ?

En soit .. non .. ça revient à ta première remarque, après si tu t'amuse à faire des jointure, il vaudra mieux de réduire les champs à sélectionner.

Citation : Spirit_3w6

Faut-il mieux multiplier le nombre de tables plutôt que de mettre beaucoup de champs dans chacune d'elles ?

Je suis pas sur qu'il existe une réponse "général".
Si tu as une base très éclatée, tu vas "perdre" à faire des tonnes de jointures, alors que si tu as des tables très grandes, tu vas "perdre" en y accédant

Personnellement je suis plutôt à essayer de rester pragmatique : décomposer ce qui est décomposable ( il est toujours moins lourd de gérer des "id" plutôt que des champs à "255caractères" mais tu perd en lisibilité ...

Citation : Spirit_3w6

Ce que j'avais compri de mes cours est qu'il vaut mieux multiplier les table. On m'a toujours dit :

Citation

si t'as un doute, fais une table!!!

Mais ceci dans le but d'améliorer la compréhension du modèle.

Qu'en est-il pour la réactivité de la base ?

oui c'est une bonne raison ... après il y a toujours moyen de faire des vues ( requêtes de jointure préchargés) ce qui revient à travailler sur des grosses tables ..

Merci pour ta réponse DrDam.

Pour la table de liaison :

Citation : DrDam

- le couple Numéro.id et Visuel.id sera-t-il unique ? ( d'après ce que tu explique : oui )

En réalité, ce couple numéros.id et visuels.id peut ne pas être unique. Un même visuel peut apparaître plusieurs fois dans un même numéro.

Citation : DrDam

- hormis les champs Numéro.id et Visuel.id tu compte "stocker" quoi dans cette table ?

Je compte y stocker ce qu'il est nécessaire d'y stocker (dans le cas ou je modifierai la structure de la base). Car cette base existe déjà.

Citation : DrDam

est-ce que les champs "commun" avec la table Visuel vont avoir des "valeur différentes" pour 1 Visuel.id donné ?

Non! les champs présents dans numéros_visuels sont identiques que ceux présents dans la table visuels. Il y a des id mais aussi des champs texte, des valeurs numériques... C'est cette structure que je ne comprend pas. Pour moi elle n'est pas logique. En gros c'est presque une copie de la table visuels dans la table de liaison.

Mais il y a aussi le même genre de données de la table numéros dans cette table de liaison.

Citation : DrDam

Je suis pas sur qu'il existe une réponse "général".
Si tu as une base très éclatée, tu vas "perdre" à faire des tonnes de jointures, alors que si tu as des tables très grandes, tu vas "perdre" en y accédant

Trop de jointures, on y perd, table trop grandes on y perd. J'ai compris, il faut trouver le bon compromis.

Citation : DrDam

Personnellement je suis plutôt à essayer de rester pragmatique : décomposer ce qui est décomposable ( il est toujours moins lourd de gérer des "id" plutôt que des champs à "255caractères" mais tu perd en lisibilité ...

La base n'est pas faite pour être lisible de toute façon.

Pour moi, à partir du moment ou la base est complexe, elle ne peut pas être lisible. Ce sont les vues qui sont là pour aider à la lecture.

Comme tu l'as si bien dis :

Citation : DrDam

après il y a toujours moyen de faire des vues ( requêtes de jointure préchargés) ce qui revient à travailler sur des grosses tables ..

Citation : Spirit_3w6

Citation : DrDam

- le couple Numéro.id et Visuel.id sera-t-il unique ? ( d'après ce que tu explique : oui )

En réalité, ce couple numéros.id et visuels.id peut ne pas être unique. Un même visuel peut apparaître plusieurs fois dans un même numéro.

donc il faut un "id" dans cette table

Citation : Spirit_3w6

Citation : DrDam

- hormis les champs Numéro.id et Visuel.id tu compte "stocker" quoi dans cette table ?

Je compte y stocker ce qu'il est nécessaire d'y stocker (dans le cas ou je modifierai la structure de la base). Car cette base existe déjà.

pense juste à vérifier que ces info ne peuvent pas être récupéré par ailleurs ( contenue dans l'une des 2 autres tables)

Citation : Spirit_3w6

Citation : DrDam

est-ce que les champs "commun" avec la table Visuel vont avoir des "valeur différentes" pour 1 Visuel.id donné ?

Non! les champs présents dans numéros_visuels sont identiques que ceux présents dans la table visuels. Il y a des id mais aussi des champs texte, des valeurs numériques... C'est cette structure que je ne comprend pas. Pour moi elle n'est pas logique. En gros c'est presque une copie de la table visuels dans la table de liaison.

si pour un Visuel.id tu récupère tout le contenu ... il y a aucun intérêt ...
dans la table de liaison tu y met ce qui est "unique" à la liaison ( l'emplacement dans le numéro où apparait le visuel pour cet affichage là) ... mais tu ne recopie pas le contenue des 2 tables ... une vue le fera pour toi et elle aura l'intérêt de rester à jour !

Citation : Spirit_3w6

Citation : DrDam

Personnellement je suis plutôt à essayer de rester pragmatique : décomposer ce qui est décomposable ( il est toujours moins lourd de gérer des "id" plutôt que des champs à "255caractères" mais tu perd en lisibilité ...

La base n'est pas faite pour être lisible de toute façon.

Pour moi, à partir du moment ou la base est complexe, elle ne peut pas être lisible. Ce sont les vues qui sont là pour aider à la lecture.

tout a fait