Discussion :

[idamarco]

Bonjour,

Je vais mettre en place un formulaire d'inscription pour les abonnés à mon site.
En dehors de leurs informations-texte (type: nom email etc...), il y aura la possibilités d'uploader des images.
Probablement 3 plus une vignette.

J'ai pensé à quelques solutions pour classer tout cela.
1) Un répertoire par abonnés.
2) Des suffixes genre login_images1.jpg login_images2.jpg etc...
Ou bien suffit il d'associer le nom de l'image à l'ID de l'abonné...?

Bref, comme c'est la première fois que je vais faire cela, votre expérience sur ce genre de projet sera intéressante.

Merci

[Jester]

Pour ma part je stockerais les images comme des blob dans la base de données.

[idamarco]

Bonjour Jester,

Intéressant cette hypothèse, je ne savais pas que la chose était possible.
Si je comprends bien, je crée un champs image et c'est le code de l'image qui remplis ce champs.

Je devine en effet l'avantage même si certains de ces avantages m'échappent peut être encore.
Concernant les inconvénients, cela ne ralentit il pas les échanges?
Autre question, il y a sur le Developpez un formulaire intéressant qui permet de vérifier l'extension du fichier uploadé.
A ton toujours besoin de cette sécurité avec le blob ou le fait que l'image soit enregistrée dans la base évite ces soucis?

[Jester]

> Concernant les inconvénients, cela ne ralentit il pas les échanges?

Je n'ai pas de chiffres, mais pas énormément je pense.

> A ton toujours besoin de cette sécurité avec le blob ou le fait que l'image soit enregistrée dans la base évite ces soucis?

Oui.

[idamarco]

Merci Jester,

J'ai été faire un tour sur le net pour voir un peu ce qu'il en est.
Je ne suis pas sur que cela soit de mon niveau.
Je me trompe peut être mais j'ai le sentiment qu'il me sera plus facile de stocker les images dans l'arborescence.
Je lis par exemple que cette dernière solution évite un risque supplémentaire à savoir que toute nouvelle requete ouvre la base et permet les intrusions.

Et comme je ne sais pas gérer ces aspects là, je préfère éviter.
Pour le moment en tout cas.

Donc, sauf avis contraire, je reste sur ma première démarche qui serait de stocker les images dans l'arborescence mais, fichier nominatif ou dossier par abonné?

[Jester]

dossier

[SQLpro]

Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/stockerimages/

A +

[idamarco]

Salut SQLPro,

J'ai lu ton article avec intérêt.

Concernant le système de stockage des photos et dans le cas de mon projet j'avais pensé à ceci:

Tu évoques le soucis de nommer et de retrouver les fichiers.
Je me disais qu'en utilisant le login de l'abonné et en créant un répertoire à ce nom, la chose était faite et me simplifiait la vie.
Exemple:

Hector3 crée un compte sur mon site, il upload des images (il y en aura 4).
Un répertoire Hector3 est crée et quand on fait une requete alors ca donne un truc du genre:
Path= ./img/$login_utilisateur/

Comme je suis très peu à l'aise avec les base de données, je tache depuis le début de n'avoir qu'une table qui contient tout.
J'entends déjà des "Rooooo" et des "Quoiiiiiii..???"


Par exemple, plutôt que de lier la table "utilisateur" avec la table "les_photos_de_l_utilisateur" je me dis qu'il suffira que j'extrais du répertoire les images que j'aurais renommé.
Exemple:
Dans le repertoire: ./img/$login_utilisateur
Photo1 photo2 photo3 et vignette.
Si j'ai besoin de la vignette, j'appelle le path et le nom standard de l'image et j'affiche ce que je veux non?
Pas besoin de rentrer les noms dans la base, je me trompe?

Que penses tu de cette approche?

L'autre solution que je proposais au début du post ressemble à celle proposée par Denis dans les commentaires sur ton article:

le nom de chaque image était tout simplement le n° de dossier du patient sur
6 positions suivi d'un numéro d'ordre sur 2 positions.

Je peux en effet avoir un seul repertoire avec, pour différencier les photos un suffixe égal au login de l'utilisateur puisque login unique...

J'aurais alors toutes les photos dans le meme repertoire.
Quelle est la meilleure solution des deux, on en revient à ma premiere question.
La reponse de Jesper était Dossier...
D'autres avis m'intéressent ne serait ce que pour explixiter la réponse de Jesper

[EDIT]
Précisement la question est la suivante:
Pour 100 utilisateurs à 4 images/utilisateurs, nous avons donc 400 images.
2 hypothèses:

D'un côté:
400 images dans le meme repertoire et je recherche ./img/$login_photo1.jpg

De l'autre:
100 repertoires contenant chacun 4 images et je recherche ./img/$login_rep/photo1.jpg

Lequel sera le plus rapide, le moins gourmand?

Sur ce principe, j'ai un primary Key qui est le champs id
N'ai-je pas interet à la virer pour faire de mon champ nom_utilisateur la primary key?

[SQLpro]

Tu évoques le soucis de nommer et de retrouver les fichiers.
Je me disais qu'en utilisant le login de l'abonné et en créant un répertoire à ce nom, la chose était faite et me simplifiait la vie.

Très mauvais. on ne mélange pas données et sémantique.
Le problème que j'évoque est simplement le fait qu'il ne faut pas trop de fichiers dans un même répertoire. Limiter à 256 est bien. Donc prévoir la création de sous répertoire régulièrement.
Pour ma part pour chaque nouveau fichier je créer un GUID et le répartit dans 16 répertoire racine en fonction du premier octet, puis si cela ne suffit pas, dans 16 autres dans chacun des 16 premiers pour le second octet...
Exemple si GUID = 285EFDCC-D224-49C3-913D-1590D4741942
Alors stocké dans ..\2\8\285EFDCC-D224-49C3-913D-1590D4741942

Par exemple, plutôt que de lier la table "utilisateur" avec la table "les_photos_de_l_utilisateur" je me dis qu'il suffira que j'extrais du répertoire les images que j'aurais renommé.
Exemple:
Dans le repertoire: ./img/$login_utilisateur
Photo1 photo2 photo3 et vignette.
Que penses tu de cette approche?

ça c'est de la merde !
Si vous n'êtes pas à l'aise dans les SGBDR, alors évitez les. Sinon acquérissez les compétences !

le nom de chaque image était tout simplement le n° de dossier du patient sur 6 positions suivi d'un numéro d'ordre sur 2 positions.

Encore un mélange de sémantique

Il existe une dernière solution, si votre SGBDR possède le type DATALINK comme IBM Db2 ou son équivalent comme FILESTREAM (SQL Server 2008), alors c'est le SGBDR qui va s'occuper de gérer le stockage des fichiers.

A +

[idamarco]

Alors stocké dans ..\2\8\285EFDCC-D224-49C3-913D-1590D4741942

Je vais m'intéresser à cette technique.

ça c'est de la merde !
Si vous n'êtes pas à l'aise dans les SGBDR, alors évitez les. Sinon acquérissez les compétences !

Si tous ceux qui ne maitrisent pas une discipline devaient s'abstenir, vous ne vous seriez jamais lancé dans le graphisme des sites que vous avez réalisés et que j'ai pu voir.
Il me semble plus intéressant d'y voir le premier pas d'un apprentissage plutôt que de la merde comme vous dîtes...

Il existe une dernière solution, si votre SGBDR possède le type DATALINK comme IBM Db2 ou son équivalent comme FILESTREAM (SQL Server 2008), alors c'est le SGBDR qui va s'occuper de gérer le stockage des fichiers.
A +

Je note également.

[SQLpro]

Si tous ceux qui ne maitrisent pas une discipline devaient s'abstenir, vous ne vous seriez jamais lancé dans le graphisme des sites que vous avez réalisés et que j'ai pu voir.

Mais je ne prétends pas ni maîtriser le graphisme, ni faire de l'art.... Je n'ai d'ailleurs pas de temps à perdre avec ce genre de chose car je m'intéresse avant tout au contenu !

A +

[idamarco]

Mais je ne prétends pas ni maîtriser le graphisme, ni faire de l'art.... Je n'ai d'ailleurs pas de temps à perdre avec ce genre de chose car je m'intéresse avant tout au contenu !

A +

Je n'ai jamais prétendu maitriser sql...