Bonjour,
 
Je fais appel à l'expérience de chacun afin de voir la solution que j'adopterai dans le cas du stockage de pièce jointes : PDF, images,....
J'ai pris comme initiative de retenir dans la base de donnée le chemin d'accès au fichier, cependant je me tâte à propos de l'organisation des pièces jointes dans l'arborescence du serveur.
 
Si un utilisateur upload une photo de profil, cette dernière va dans un dossier avec son id+nom ?
Dans le cas ou un utilisateur upload un document pour d'autres personnes (par exemple facture ) vaut-il mieux créer un répertoire (facture) chez la personne qui publie le document ?
 
Il y a encore de nombreuses solutions, pourriez-vous me dire comment avez-vous l'habitude de procéder avec les avantages/désavantages ?
 
Merci
 
Bonne journée.

Quand on regarde Mediawiki, il évite de lier les fichiers à des ID (d'articles ou users). Il utilise des répertoires portant comme nom un numéro de 0 à 9. Chaque répertoire possèdes 10 sous-répertoires reprenant le nom du répertoire parent + un n° de 0 à 9. Ex : 9 pour le répertoire parent puis 90, 91, ... 99 pour les sous-répertoires.
 
Tu peux partir aussi sur des répertoires avec des noms de type hash md5.

Merci pour cette réponse rufo.
 
Au vu des conseils que tu m'as donnés dois-je comprendre qu'il n'y a pas vraiment de méthode avantageuse, chacun organise les fichier sur son serveur de la façon la plus logique qu'il l'entend ?
 
Merci.

En quelque sorte. Ca dépend aussi pas mal de la nature des fichiers déposés et du volume de consultation.
Ex : si t'as des fichiers avec des extension très hétérogènes, tu peux envisager de prendre comme clé de hash, l'extension (contrairement à si t'as que des pdf ou .doc)
 
Une chose est sûre de mon point de vue, il ne faut pas stocker le fichier dans la BD. Certains le font et présentent des arguments (notamment, avoir toutes les données au même endroit, facilitant la migration des données ou leur transport dans un seul "fichier" ).

Bonjour
Justement j'ai fait ça récemment.
 
J'ai créé une table "pj" (pièces-jointes) contenant l'identifiant de la pj (typiquement le md5 de son contenu), le nb de fois où elle est référencée dans la bdd et bien évidemment son contenu. Avec un petit trigger associé à l'insert qui, si la pj y est déjà, se contente d'incrémenter le nb_liens. De même un trigger associé au delete se contente de décrémenter le nb liens et l'efface réellement si celui-ci tombe à 0.
 
Et dans la table à laquelle elle est référencée (par exemple l'image d'une moto alors elle sera référencée dans la table "moto" ) j'ai un champ "id_pj" (lié au champ "pj.id" ci dessus) et "chemin".
 
Ainsi, quand un utilisateur insère une pièce-jointe dans sa base, il y a le nom de la pj à l'endroit où il s'en sert mais le contenu est stocké ailleurs. S'il la réinsère une seconde fois il y a alors de nouveau le nom (voire un autre si entre temps il a changé) mais le contenu reste stocké qu'une fois. Et s'il veut visualiser la pj, le nom me donne l'extension de la pj ce qui me permet de descendre la pj dans un fichier temporaire mais avec la bonne extension et ensuite quand je l'ouvre c'est l'OS qui associe l'extension au logiciel dédié à sa visualisation.
 
J'ai d'ailleurs pensé plusieurs fois que le nom ne me sert pas à grand chose et que seule l'extension me suffirait mais ça rassure l'utilisateur, quand il ouvre la bdd, de voir la pj avec le nom qu'il lui avait mis. Alors c'est marrant parce que parfois ils me disent "ma pièce-jointe je l'ai appellée 'pj.pdf' mais dans la base il y en a d'autres qui se nomment 'pj.pdf'" et je leur réponds "c'est pas grave, la bdd sait les différencier". Et ça ne les étonne même pas de voir que la pièce-jointe se nomme "G:\pj.pdf" (G: étant la lettre de la clef USB qui contenait la pj quand elle a été insérée en bdd) et qu'ils arrivent à ouvrir la pièce-jointe alors que la clef n'y est plus...
 

Justement c'est ce qui m'avait été demandé. Parce que j'avais aussi pensé stocker les pièces-jointes dans un dossier classique géré par l'OS et ne référencer en bdd que le chemin des pj stockées. Cela aurait été possible. Mais quand j'en ai parlé aux utilisateurs, ils ont préféré avoir la pj stockée en bdd afin de n'avoir qu'un dump à emporter s'ils voulaient la redéployer ailleurs. Donc comme tu le vois, rien n'est jamais "sûr" et de mon point de vue les solutions à adopter dépendent aussi du besoin énoncé...

Ben tu vois, tu viens justement de donner l'argument que mettre les fichiers dans la BD, c'est plus facile pour migrer la base
Sauf que moi, j'y vois un pb de perfs. Avec mon système, quand on veut télécharger le fichier, c'est juste apache qui va chercher sur le HDD le fichier et qui le pousse à l'utilisateur. Dans ton cas, y'a en plus le transfert entre le sgbd et apache. Si t'as beaucoup d'accès concurrents, ça risque de faire un goulet d'étranglement, a fortiori si tu es sur une architecture répartie où ton sgbd n'est pas sur le même serveur qu'apache
 
Sinon, pourquoi tu stockes dans la BD le path du fichier qui a été uploadé et pas simplement le nom du fichier dans la mesure où ce path ne correspond à rien pour le serveur

Plutôt pour la déployer ailleurs...
 

Là ton affirmation d'origine est mieux justifiée. Sauf que mon appli n'est pas une appli html mais client-serveur direct. Donc... pas de apache intermédiaire.
 

Comme je l'ai dit, pour rassurer l'utilisateur qui voit le path qu'il avait lui-même positionné. Effectivement le path ne correspond à plus rien de concret. Même le nom ne correspond à rien vu que quand j'affiche une PJ, je commence par la créer dans le dossier temporaire de l'utilisateur et son nom c'est l'id stocké en bdd (donc une suite md5). J'y rajoute ensuite l'extension pour que l'OS sache comment l'ouvrir et voilà.
Donc le path ne sert à rien mais (mis à part qq octets inutiles) il ne gêne pas.  
D'ailleurs je viens de programmer un petit compteur. Nous avons 2402 PJ (poids global de 289M) et la somme de leurs noms dans les différentes tables fait 161789 octets soit grosso-modo 160k. Et la bdd entière fait 659M donc c'est vraiment négligeable...

Tes PJ prennent donc 43% de ta BD; ça fait beaucoup, je trouve. Suivant les sgbd, ça pourrait nuire aux perfs à la longue. Ca dépend pas mal de comment sont gérer les champs de types blob (ou équivalent).
 
Mais bon, comme je le disais, y'a des "pour" et des "contre" pour les 2 techniques. Dans ton cas (pas d'appli web), j'ai pas vraiment d'argument pertinent "contre". Ma solution a le mérite de fonctionner niveau perfs qu'on soit en client/serveur direct ou en appli web. ta technique, en contexte web, est plus discutable.

Oui mais chez-moi les PJ sont dans une table "à part" qui n'est invoquée que quand l'utilisateur veut afficher la PJ en question. Et il y a bien entendu un index sur l'identifiant.
Les perfs dans les sgbd dépendent plutôt des jointures dans les requêtes et des index positionnés non ???
 

C'est du postgres, le top du top de la bdd GPL quoi...