Bonjour,
 
j'aimerais avoir qques conseils quant à l'évolution de ma DB... en fait elle me sert a gérer des photos de concerts, et voici la structure de base :  
 

 
 
Donc ici on voit que la table concert contient les informations du lieu, de la date etc. le table groupe, elle, contient donc les informations des groupes. et comme un groupe peut jouer dans plusieurs concerts et qu'un concert peut avoir plusieurs groupes a l'affiche, la table galerie sert de lien entre les 2...  
 
comme je veux que la table photos contienne également les informations de groupe et de concert, ces infos sont également reprises dans cette table.
 
 
Maintenant, la DB s'est un peu développée suite à l'arrivée de nouveaux membres, qui peuvent eux aussi ajouter leurs photos. Mais j'ai qques petits soucis pour bien gérer tout ça : en fait je me trouve confronté à 2 choix :  
 
* soit ajouter simplement le champ photographe dans chacune des 2 tables concernées, c'est-à-dire les tables galerie et photos.  
Mais je trouve que cela en fait une structure assez compliquée, ainsi que pas mal de doublons et de données superflues...
 

 
* ou alors ajouter un identifiant unique à ma table galerie, qui contiendra toujours les informations de concert de groupe et de photographe, mais le table photos, quant à elle, n'aura qu'a recevoir l'identifiant de galerie pour retrouver ces infos...
 

 
 
Quel est le mieux ?
 
Merci !
 
PS. Au cas où vous vous poseriez la questions, oui ce sont des screenshots de MS-Access, j'ai recréé les tables en vitesse sous Access pour pouvoir afficher les relations + facilement !

le 2ème schéma relationnel me semble le plus adapté

euh le 2è en comptant le schéma de base (asso ternaire) ou la 2è soluce (id unique dans galerie) ?

2 remarques à l'arrach'
 
- 1 photo ne peut avoir qu'un photographe, pourquoi ne pas faire le lien directement entre la table users et la table photos ?
 
- pourquoi avoir créé un champ id_galerie : tu pourrais mettre id_photo dans la table galerie et supprimer galerie de la table photo, non  (et rajouter un champ "photo_nom" )

bin une photo ne peut aussi avoir qu'un groupe et un concert, donc dans ce cas ce serait le schéma de la 1ere soluce pour toi ?
 
mais dans galerie je peux pas mettre id_photo puisque pour uen galerie je peuxa voir jusqu'a 15 photos

Ben c'est vrai que ça dépend de ce que tu veux.
 
Dans mon idée, la table "gallerie" ne sert vraiment que de table de liaison.
 
Donc après un concert, les phases à faire (en décomposant)
 
Tu saisis les données concernant le concert
Tu saisis les noms de groupes (s'ils ne sont pas dans la base)
Si tu es un nouveau photographe, tu "te" saisis
 
Ensuite tu saisis une photo à la fois.
Une photo a un auteur, un concert, un groupe.
 
Dans ta table gallerie, tu auras donc autant d'entrées que de photos, ce qui est le plus logique.
 
Quant au lien avec le photographe, le doute m'assaille...
 
C'est vrai que le 3ème schéma me paraît a priori le meilleur (avec la modif indiquée), mais je suis pas bon en ternerisation.
 

ah bin en effet, tu me fais remarquer que ma table galerie ne contenait absolument rien d'autre que la table photos ne contenait pas déjà...  
 
donc pareil pour la 1ere solution, ya double emploi entre galerie et photos... donc ce sera soit la 3è soluce telle quelle, soit une solution avec une table en moins !

merci

alors finalement c'est mieux laquelle?

?

svp

moi je vote la 2eme soluce, j'aurais fait comme ça.

 
Eh bé en y réfléchissant le plus simple me semble l'utilisation de 4 tables
 
-user (=photographe)
-concert
-groupe
 
-photo
 
Dans les 3 premières, les champs contenant les infos que tu veux et une clé primaire id (auto_incr)
 
Dans photo
ph_id (clé primaire, auto_incr)
ph_nom (nom/url de la photo)
user_id (relation avec user)
concert_id (relation avec concert)
groupe_id (relation avec groupe)
 
Tu as donc une entrée unique pour chaque photo : c'est logique, une photo est une unité.
 
Ainsi tu peux faire les affichages que tu veux de manière simple.
 
Affichage/recherche par groupe, photographe, concert.
 
Ou avec plusieurs critères
(SELECT ph_nom FROM photo WHERE concert_id=x and groupe_id=y and user_id=z)
 
Je ne vois pas trop l'intérêt (je peux me tromper) d'une table gallerie, puisque tu peux combiner les critères à volonté !
 
EDIT : tu perds la relation groupe/concert avec ce système (mais le but est d'afficher des photos, pas le nom des groupes par concert).
Et au moins tu peux avoir plusieurs photographes par concert !

ok cool ta solution me semble tres bonne !
 
et pour ton edit, je dois aussi afficher le nom des groupes par concert, mais je ne perds pas ma relation groupe/concert puisque le role qui etait tenu par galerie l'est maintenant par photo, on peut qd meme tout retrouver

 
Vi j'étais en train de réfléchir à éditer mon edit...
 

En regardant vite fait je pencherais sur le troisième schéma, la table galerie faisant le lien entre concert, groupe et photos.
Par contre je ferais le lien de la table user avec la table des photos, la photo n'appartenant qu'à un seul utilisateur...
S'il n'y a bien sur qu'une galerie commune à tous les Utilisateur pour un groupe et concert donné sinon.
Sinon s'il y a une galerie par groupe, concert photographe la solution telle quelle

Pas tout lu.
 
Simplement, avec le second shéma, un seul photographe peut prendre un même groupe lors d'un même concert, ce qui me semble est une erreur.
 
Moi je ferais un truc du style :
 
PHOTO
-------
ID_PHOTO
ID_USER
ID_CONCERT
ID_GROUPE
...
 
GROUPE
-------
ID_GROUPE
...
 
CONCERT
---------
ID_CONCERT
...
 
PARTICIPE (mieu que "galerie" à mon sens)
---------
ID_CONCERT
ID_GROUPE
 
 
USER
-----
ID_USER
...
 
 
Si tu ne comptes pas afficher les apparitions des groupes non couvertes par un photographe, alors tu peux virer la table "participer", à moins qu'elle apporte quelquechose ("première partie", durée, etc.)