Discussion :

[renaud26]

Bonjour à tous,

Je sollicite votre avis à propos de ce qu'il convient de faire dans le cas suivant :

- Je voudrais que mes membres puissent publier leur galerie photos.
- Chaque galerie a un nom, elle est limitée à 10 images.
- Chaque image peut avoir une légende.
- La galerie peut être publique ou privée (vue), active ou non.
- Le membre peut en publier autant qu'il le souhaite.
- Il peut y avoir beaucoup de membres

Proposition 1 : la grande table

Une table pour tout: nommons-la "galeries"
id | id_membre | nom | vue | actif | img1 | leg1 | img2 | leg2 etc..-> 10

Proposition 2 : 2 tables

Une table "galeries"
id | id_membre | nom | vue | actif

Une table "galerie_images"
id | id_galerie | img1 | leg 1 | img2 | leg2 etc...
ici peut-être que id_galerie peut être primaire sans id ?

Ou une d'autres solutions ?
Des deux, quelle est la plus rapide, la plus fluide, la plus exploitable ?

Toujours dans le soucis d'optimisation, pouvez-vous me conseiller au sujet des clefs primaires (si la proposition 2 est retenue) pour les futures requêtes jointes ?

Pouvez-vous également me dire le meilleur stockage des images ?
- Varchar avec chemin
- Autres ?

Merci d'avance pour vos précieuses lumières.

[Maljuna Kris]

Saluton,
En fait, il te faut aller plus avant dans la décomposition.
Une image est en association avec une galerie qui est en association avec un membre.
L'arité des images, dans la table galerie_images que tu présentes, ne respecte pas les formes normales.
Pour ce qui concerne le stockage des images à proprement parler, tu trouveras une abondante littérature qui conseille, majoritairement, de ne pas les mettre dans les bases de données, mais d'y stocker leur adresse (URI), majorité à laquelle je me rallie, bien évidemment.
Pour le reste je me permets de te recommander, par exemple, la lecture de cette traduction du Chapitre 6 Database Design de Using SQLite by Jay A. Kreibich Ed. O'Reilly.
Il y a sinon, sur ce forum,d'excellents tutos afférents à la conception des bases de données.

[punkoff]

Bonjour,

Vous devriez faire un tour dans la partie modélisation de developpez.

La deuxième se rapproche d'une solution exploitable.



D'un point de vue MCD, d'après ce que je comprend des RG :
Membre-(0, n)----possède----(1,1)-gallerie-(0,10)----contient----(1,1)-Image


Par contre est-ce qu'une image peut-être dans plusieurs galeries ?
Et est-ce qu'une gallerie peut être possédée par plusieurs membres ?

Car ca changerai certaine chose


Toujours est-il qu'au passage au MPD (PK soulignées) :
t_gallerie_gal (gal_id, membre_id (FK), gal_nom, gal_desc,...)
t_image_img (img_id, gal_id (FK), img_acces, img_desc, ....)

La limites des 10 images par gallerie il faudrai la gérer avec un trigger / contrainte check.

Ca a l'avantage d'être évolutif assez facillement, si vous coder correctement votre application.

[renaud26]

Bonjour à vous, et merci pour vos réponses.

Je vais lire les tutos conseillés par Maljuna Kris.

Pour répondre à punkoff :

- Oui, je pense qu'une image peut faire être rangée dans plusieurs galeries. Mais ça n'est pas un problème : j'encode le nom des images, il n'y aura donc pas de doublons.

- Non, les galeries ne seront pas partagées par plusieurs membres : chacun a ses galeries.

Par contre, je ne pige pas bien ce passage :

Toujours est-il qu'au passage au MPD (PK soulignées) :
t_gallerie_gal (gal_id, membre_id (FK), gal_nom, gal_desc,...)
t_image_img (img_id, gal_id (FK), img_acces, img_desc, ....)

Peux-tu préciser ?

[punkoff]

- Oui, je pense qu'une image peut faire être rangée dans plusieurs galeries. Mais ça n'est pas un problème : j'encode le nom des images, il n'y aura donc pas de doublons.

Ah mais ceci change certaine de chose.


Ce n'est plus aussi simple du coup.

Quand vos utilisateurs vont uploader une image, est-ce que celle-ci devra obligatoirement être dans une gallerie ?

Concernant le fait qu'une image puisse être rangée dans plusieurs galerie, comment le gérez-vous applicativement (option copier dans une autre galerie) ?


Pour la table t_gallerie_gal :
gal_id : primary key
membre_id : foreign key qui référence la primary key de la table membre.

les autres champs bein sont basiques.



Pour la table des photos, il faudra surement rajouter uen notion d'ordre afin que l'utilisateur puisse classer ses 10 photos. (idem pour les galleries ceci dit)

[renaud26]

Re,

Quand vos utilisateurs vont uploader une image, est-ce que celle-ci devra obligatoirement être dans une gallerie ?

Absolument : le membre devra commencer par créer une ou plusieurs galeries en les nommant.
Cela fait, il pourra uploader jusqu'à 10 images par galerie.

Chaque membre dispose en outre d'un dossier "galeries", contenant un dossier par galerie et les images à l'intérieur.
Donc ça répond à la question 2 : il met ce qu'il veut dans chaque galerie, et si il upload une même image dans plusieurs galeries, ce n'est pas un problème.

Pour ce qui de l'ordre des galeries et des images/galerie, oui, bonne idée.

Donc on pourrait imaginer :

Une table "galeries"
id (PK) | id_membre (FK) | nom | vue | actif | ordre

Une table "galerie_images"
id_img (PK) | id_gal (FK) | legende| ordre

Par contre, même avec les tables innoDB je ne vois pas comment insérer une foreign key avec phpMyAdmin ??

[CinePhil]

il met ce qu'il veut dans chaque galerie, et si il upload une même image dans plusieurs galeries, ce n'est pas un problème.

Ce qui veut dire que tu auras physiquement plusieurs fichiers image ayant en fait le même contenu (la même image) mais sous un nom différent.
Du point de vue des données, une image, en fait un fichier d'image n'est que dans une galerie.

Une table "galerie_images"
id_img (PK) | id_gal (FK) | legende| ordre

Il te manque une colonne pour le nom du fichier.
Et j'appellerai plutôt la table "image" vu qu'elle contient bien les informations sur les images et non pas sur les galeries. À moins que tu aies une autre notion d'image dans ton modèle de données et que tu veuilles les distinguer ?

Par contre, même avec les tables innoDB je ne vois pas comment insérer une foreign key avec phpMyAdmin ??

Sous le cadre donnant la liste et les caractéristiques des colonnes, tu dois avoir un lien "Gestion des relations".

[renaud26]

Bonjour,

Ce qui veut dire que tu auras physiquement plusieurs fichiers image ayant en fait le même contenu (la même image) mais sous un nom différent.
Du point de vue des données, une image, en fait un fichier d'image n'est que dans une galerie.

Certes ! ce n'est pas vraiment gênant. Je pense que cela a peu de chance d'arriver.

Pour le nom de la table, je pensais à "galerie_images" ou "images_galeries" puisque il y aura la relation galerie / images. Mais comme je n'ai pas d'autre table "images"...

Et pour ce qui est du lien "Gestion des relation" c'est OK, j'ai vu. Merci.
Quel est le réel avantage de cette foreign key ?

[CinePhil]

[quote=renaud26;6352238]
Pour le nom de la table, je pensais à "galerie_images" ou "images_galeries" puisque il y aura la relation galerie / images. Mais comme je n'ai pas d'autre table "images"...[quote]
Les tables sont issues du modèle conceptuel de données (méthode Merise) ou du diagramme de classe UML.
Comme son nom l'indique, le modèle conceptuel de données (MCD) modélise des concepts tels que "membre", "galerie" "image" représentés par des rectangles qu'on appelle "entité type" ou par simplification "entité".

Ces entités sont issues des règles de gestion que je te conseille d'écrire si tu n'as pas l'habitude de la modélisation des données.

Voici tes règles de gestion :
1) Un membre peut posséder plusieurs galeries et une galerie est possédée par un seul membre.
2) Une galerie peut contenir jusqu'à 10 images et une image n'est contenue que dans une seule galerie.

Ces règles de gestion entraînent la création du MCD donné par punkoff :

Membre-(0, n)----possède----(1,1)-galerie-(0,10)----contient----(1,1)-Image

Les entités types sont "membre", "galerie" et "image" et le fait que les images soient en relation avec les galeries donne l'association "contenir".

Vu les cardinalités des associations, il n'y aura pas de table associative donc aucune table n'a de raison de s'appeler "galerie_image" ou "image_galerie". Les seules tables seront celles issues des entités types du MCD.

Et pour ce qui est du lien "Gestion des relation" c'est OK, j'ai vu. Merci.
Quel est le réel avantage de cette foreign key ?

Une clé étrangère référence l'identifiant d'une autre table. Cela permet un contrpole automatique sur la saisie des données et garantit leur cohérence.
Il sera ainsi impossible que la galerie d'identifiant 12 soit possédée par le membre 124 s'il n'y a pas de membre 124 ou qu'une image 8125 soit contenue dans la galerie 945 si celle-ci n'existe pas préalablement.
Autre avantage, avec la contrainte ON DELETE CASCADE, si un membre est supprimé, cela entraînera la suppression automatique par le SGBD de ses galeries et des images qu'elles contiennent.
Attention toutefois ! Comme en base de données tu ne stocke que la référence du fichier d'image et non pas le fichier lui-même, ton disque serait alors chargé de fichiers devenus inutilisables !

[renaud26]

Merci beaucoup pour toutes ces intéressantes précisions.
Bonne soirée.