Discussion :

[PommeCassis]

Bonjour,

je précise pour commencer que je ne suis pas du tout a l'aise avec les bdd. Ne me lyncher pas trop vite.

Alors c'est simple, j'ai des articles qui peuvent contenir plusieurs photos, un article possède aussi forcement une photo dites "de couverture". Des articles peuvent posséder la même photo.

A partir de ça j'hésite sur quelle structuration adopter:

Solution 1:

Avantage: requête plus rapide pour accéder à la couverture
Inconvénient: Vraiment bizarre et incohérent je trouve

Solution 2:

Avantage: plus logique
Inconvénient: requête plus lourde car condition pour savoir si l'image est en couverture ou non

Peut être que les performances sont négligeables d'une solution à l'autre. La question se pose car je voudrais afficher de longue liste d'articles avec seulement la photo de couverture, alors que les autres photos, ne serviront que peu souvent.

Ou peut être que je peux gérer ça autrement...

Ça me tracasse et me désole de passer autant de temps pour un problème aussi banal

Merci d'avance pour votre aide

[CinePhil]

Le premier schéma peut créer :
- d'une part une redondance puisque l'identifiant de la photo de couverture figurera à la fois dans la table articles et dans la tables articles_photos ;
- d'autre part une incohérence de données car la photo de couverture pourrait ne pas figurer parmi les photos de l'article.

Le second schéma est donc meilleur.

Inconvénient: requête plus lourde car condition pour savoir si l'image est en couverture ou non

je voudrais afficher de longue liste d'articles avec seulement la photo de couverture

Pas si compliquée que ça la requête :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
SELECT a.name, p.url
FROM articles AS a
INNER JOIN articles_photos AS ap ON ap.article_id = a.article_id
  INNER JOIN photos AS p ON p.photo_id = ap.photo_id
WHERE ap.est_en_couverture = TRUE
ORDER BY a.name

[PommeCassis]

Merci beaucoup CinePhil, j'y vois déjà plus clair.

Par contre la requête ne me dérange pas, j'utilise un framework alors le sql je n'y touche pas, c'est juste au niveau de la consommation de ressources mais çà doit être négligeable.

Encore merci pour ton aide

[JPhi33]

Bonjour,

Le second schéma peut créer :
- d'une part une gestion très lourde des requêtes de mise à jour (insertion, modification, suppression) de la table articles_photos ;
- d'autre part une absence de photo en couverture ou une multiplicité de photos en couverture puisque le booléen est_en_couverture est présent dans l'association entre les tables photos et articles.

Le premier schéma est donc meilleur.

Inconvénient: Vraiment bizarre et incohérent je trouve

Ni bizarre, ni incohérent comme le montre le MCD ci-dessous issu de la rétro-conception :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
[ Article ]--0,n----( article_photo )----0,n--[ Photo ]
     |                      ^                     ^
     |                      |                     |
     |                     (?)                    |
     |                      |                     |
     |                      |                     |
     +--1,1-------( a_pour_couverture )------0,n--+

On notera que les cardinalités de la patte Article---a_pour_couverture sont 1,1 car :

un article possède aussi forcement une photo dites "de couverture".

Le point d'interrogation rouge au milieu de la flèche qui va de "a_pour_couverture" vers "article_photo" est une contrainte sémantique pour laquelle il y a deux options. On peut remplacer ce '?' par :

• I : c'est une contrainte d'inclusion signifiant que la photo de couverture doit figurer parmi la liste des photos de l'article. Dans ce cas, les cardinalités de la patte Article---article_photo doivent être 1,n.
• X : c'est une contrainte d'exclusion signifiant que la photo de couverture ne figure pas parmi la liste des photos de l'article ; elle vient compléter cette liste.

Il existe aussi la possibilité d'ôter la contrainte mais dans ce cas il n'y a plus de règle, la photo de couverture pourra figurer ou pas dans la liste des photos de l'article. Et ceci pourra varier d'un article à l'autre. Cette situation d'incertitude n'est pas souhaitable.


Il semble préférable de poser une contrainte d'exclusion car :

je voudrais afficher de longue liste d'articles avec seulement la photo de couverture, alors que les autres photos ne serviront que peu souvent.

Il faut éviter le second schéma à cause de la gestion des mises à jour. Considérons un exemple simple de la table article_photo :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
article   photo   est_en_couverture
a1        p1      Oui
a1        p2      Non
a1        p3      Non

Je souhaite ajouter la photo p4 à l'article a1. La question cruciale qui se pose est : suis-je en train d'ajouter la photo de couverture ?
Pour le savoir, il a forcément fallu, d'une manière ou d'une autre, exécuter une requête préalable afin de déterminer s'il existe déjà une ligne ayant la valeur "Oui" dans la colonne "est_en_couverture" pour a1. Si on ne prend pas cette précaution, on risque de se retrouver rapidement avec 2, puis 3, puis n photos de couverture dans le même article.


Inutile de démontrer que le problème inverse se pose pour la suppression d'une photo.

[PommeCassis]

Merci bien JPhi33.

C'est un peu perturbant, les avis divergent. Je pense que c'est surtout une histoire de compromis.

Au début j'étais plutôt parti sur le premier schéma mais je trouvais ça peu logique d'où ma question. Si ces deux relations sont justement logiques, ça règle le problème que j'avais vis à vis du premier schéma.

Donc je vais utiliser le premier qui en plus me facilite la tâche avec le framework que j'utilise. CakePHP est effectivement pas trop copain avec les tables de jointures possédant des champs supplémentaires.

Autrement pour les contraintes, une contrainte d'inclusion serait plus simple à gérer mais la contrainte d'exclusion évite une petite redondance si j'ai bien compris. Je pense opter pour une inclusion car cela semble plus simple pour changer la couverture d'un article par une autre photo de l'article. Ça m'éviterait d'effacer puis de remettre un couple de clé dans articles_photos mais la encore j'hésite un peu.

Enfin bref c'est pas important, je verrai ça un peu plus tard. Vous m'avez déjà beaucoup aidé, merci.