images bdd et affichage

[hercull]

Bonjour,

Je voudrai que les utilisateurs puissent uploader un nombre aléatoire d'images associé à leur compte.

Seulement, actuellement j'ai 2 manières de procéder, soit je prévois un champs dans ma bdd réservé au lien de l'image( pour un petit nombres d'images), soit lorsque c'est un nombre indéfini d'images je créer une table qui stock le nom de l'utilisateur ainsi que toutes les images uploader.

Seulement cela n'est pas réalisable je pense avec un grand nombre d'utilisateur, car créer une table par utilisateur me semble être le contraire d'optimiser.

Quel méthode utilisez vous?

[Xenos]

Oulà, oui, une table par utilisateur, ce n'est pas une bonne approche.

Pourquoi ne pas ajouter une table indiquant qui a uploadé quoi?

Code :

imageId [UNSIGNED INT, PRIMARY KEY, AUTO INCREMENT] ; userId [UNSIGNED INT, INDEX] ; imageName [VARCHAR / TINYTEXT ]

Ainsi, chaque image se voit dotée d'un identifiant unique (imageId); est associée à un et un seul utilisateur (userId), et possède un nom (toutes les images pouvant être dans un même dossier "/images/user-uploaded/..." avec ou sans sous-dossier "images/user-uploaded/user-XXX/...").
De plus, cela se greffe sur la BDD existante, au lieu de modifier la structure des tables des utilisateurs.

---

On peut aussi choisir la variante à un seul index, en focalisant l'imageId sur chaque utilisateur:

Code :

userId [UNSIGNED INT] ; imageId [UNSIGNED INT, AUTO INCREMENT] ; imageName [VARCHAR / TINYTEXT ]
PRIMARY KEY (userId, imageId)

Ce serait plus léger du point de vue des indexes, mais le champ imageId devient délicat à traiter (il faut déterminer sa valeur à chaque insertion, de sorte que l'index reste unique, et là, je sèche). et l'auto-increment peut s'appliquer au second champ de la clef primaire sur MySQL/MyISAM. Pour InnoDB, je n'en sais rien.

---

Voir, ne pas considérer de nom d'image: seulement son extension, et le chemin vers l'image se construit alors naturellement, sous la forme "/images/user-uploaded/user-<userId>/image-<imageId>.<image-extension>"

Code :

userId [UNSIGNED INT] ; imageId [UNSIGNED INT, AUTO INCREMENT] ; imageExtension [ENUM('png', 'jpg', 'tiff',...)]
PRIMARY KEY (userId, imageId)

[hercull]

Merci, donc une seul table contenant tous les liens de toutes les images de tous les utilisateurs est une façon optimiser de traiter la chose?

Même si cette table risque d’être vraiment gigantesque au bout d'un moment, Cela ne risque pas de poser un problème futur? qu'en pensez-vous?

[Aedius]

Même si cette table risque d’être vraiment gigantesque au bout d'un moment, Cela ne risque pas de poser un problème futur? qu'en pensez-vous?

vraiment gigantesque ?
tu penses avoir plusieurs dizaine de millions de lignes ?
Je pense que tu auras d'autre soucis : espace disque et bandes passante bien avant d'avoir un soucis de bdd.

[Xenos]

Oui, comme dit Aedius, la limite de la BDD ne sera certainement jamais atteinte sans, auparavant, avoir creuvé les plafonds de l'hébergeur.

Sinon, si on quantifie au "pifomètre" (excellent instrument de mauvaise mesure), chaque ligne doit faire dans les 50octets (INT, TINYINT, TINYTEXT ou ENUM), index inclus. De là à atteindre les 100Mo (limite qu'on peut considéré comme plausible en voyant les offres d'entrée de gamme d'OVH), il faudrait bien un million d'images... et encore! Le "imageName" peut être remplacé par un "imageExtension" de type ENUM('png','jpg',...) et le path de l'image devient"images/user-<userId>/img-<imageId>.<imageExtension>", ce qui réduit encore la taille de chaque ligne (même, la taille devient FIXED, ce qui est plutôt une bonne chose point de vue perfs).

Pour ce qui est de la vitesse de traitement de la requête, la clef primaire (userId, imageId) sera extrèmement efficace pour chercher un ou plusieurs images d'un utilisateur. Si besoin, on peut décorréler les deux colonnes (PRIMARY KEY(imageId) AUTO_INCREMENT, INDEX(userId)) et le SGDB gèrera sans soucis des millions d'entrées.

[hercull]

C'était effectivement du point de vue de la vitesse d’exécution de la requête que je me posais des questions une fois que le nombres d'enregistrement devient important.
Cela répond à ma question.

Autre chose pour enregistrer des commentaires, dois-je utiliser la même méthode(qui me paré adapté) ou y a t'il des autres éléments à prendre en compte?

[Xenos]

La même méthode semble adaptée.
imageId, userId, comment
Trois colonnes suffiraient pour des commentaires simples et uniques, avec une PRIMARY KEY(imageId, userId)); sinon (si on autorise un utilisateur à commenter plusieurs fois une image), il faudra un commentId unique à chaque commentaire (1 colonne de plus).

Aussi, il ne sera pas possible de lier les messages entre eux et de faire des "répondre au commentaire de <truc>" sans devoir ajouter une colonne ("parentCommentId" par exemple pour stocker l'id du commentaire auquel le commentaire courant répond) ou ajouter une table (table de liens, mais cette solution est plus adaptée aux relations N→N plutôt que 1→N).

[hercull]

Ok merci beaucoup.