Reprise du message précédent :

appleG

Il y a quelqu'un qui connait un peu l'organisation du stockage physique des documents dans une ged ?

Allez, au pif: stockage de zip sur le filesystem. Au pire un gros BLOB en BD. Avec un md5 pour assurer l'intégrité des données. Ca te va ?

bah non regarde jubijub il est payé 1.5ratibus pour se taper des polonaises

 
je crois que tu as depasse son niveau technique au mot zip
 

J'ai rajouté md5 pour bien faire.

 
ici, c'est stocké dans un répertoire non accessible depuis l'extérieur, chaque fichier est renommé avec un id , et un script se charge de vérifier qu'il y a les bons droits avant de lire un fichier

C'est des polonais qu'il se tape, et il la leur met bien profond. Et vice versa.

C'est trop facile c'est un Transformers lui

Ca c'est la version officiel.
Mais quand il va "superviser sur place", tu penses bien qu'il inspecte en profondeur
(et s'impregner de la culture locale, pour anal-yser les specificites)

Un outil de gestion de version un peu récent pourrait faire plus ou moins le même genre chose, a priori.

T'es jaloux ?

Clearcase le stocke dans 3 endroits differents et verifie la taille pour s'assurer de l'integrite ?

Je prefere les vietnamiennes. Et ils travaillent davantage et boivent moins.

On parle d'outil récent, là, pas d'usine à gaz moisie.
Mais je pense que CC s'assure effectivement de l'intégrité, ouais.

 
En gros pour l'instant on stocke l'ensemble des fichiers dans 1 seul dossier sur le serveur.
Du coup on voit bien que c'est nul, que ce soit pour la portabilité sur un autre serveur ou même pour l'accès aux données sur un grand nombre de fichier.
J'avais prévu de stocké en base un chemin virtuel vers le dernier dossier parent et de faire des subdivisions par année puis par projet et enfin par type de document. Çà va résoudre le pb de changement de serveur vu qu'il suffira de changer le dossier parent dans les paramètres.  
Mais qu'est ce que je peux faire (ou est ce qu'il y a quelque chose de possible) pour améliorer le temps d'accès ou de sauvegarde des fichiers ?

Pareil ici mais il risque pas d'y avoir un pb avec des fichiers volumineux ou de grand nombre de fichiers ?
Quid des chemins des fichiers enregistrer en base,ils sont en absolu ?

Quelques idées en vrac: le plus simple est à mon avis filesystem de fichiers gzippés plus BD. Le plus sophistiqué auquel je pense est un outil comme git ou mercurial (qui vont faire à peu près ce que fait le système de flo850 et gèreent naturellement la portabilité) + BD. Accès par HTTP.
Améliorer le temps d'accès est plus important que la sauvegarde, vu qu'on ne sauvegarde qu'une fois alors qu'on récupère N fois.

pour le nombre de fichier, ca pose pas de problème pour nous ( mais il n'y a que dans les 8 000 fichiers actuellement , et le plus gros ne dépasse pas les 300 Mo )

en base, il y a juste l'id du fichier( un champ en autoincrement), qui est aussi le nom du fichier sur le serveur de fichier  sur le fs , le chemin d'acces réel au fichier est donnée par :

• le repertoire de stockage défini dans la config
• l'id du fichier

la table fichier contient :

• un id
• nom d'origine
• date de publication/modification, avec les login associés
• un flag pour dire si je dois le réindexer ou pas

il y avais ça au début, mais c'est la merde , tu te regtrouve a deplacer /copier des fichiers physiques, simplement parceque le projet est reporté a l''année suivante

franchement, un gros repertoire, et c'est la base de données qui fait l'affichage

EDIT ; tu as combien de fichiers ?

L'affichage se fait uniquement par l'appli/bdd.  
 
A priori faudrait penser le truc pour 500K fichiers pour un total max de moins de 10To.

gzipper les fichiers va pas me ralentir l'accès aux fichiers ?

je ne suis pas sur qu'utiliser le nom du fichier soit nue bonne idée, suivant le FS utilisé, tu vas pas avori les mêmes caractères spéciaux

mais par contre , utiliser un id / une chaine fiable  pour partitionner, et ça devrai rouler

a ouais, on est pas sur la même echelle
alors il va falloir partitionner

C'est de ça que j'ai peur.
 
 
En gros pour un meilleur temps d'accès, il faut repartir au max les fichiers sur 1 seul niveau de dossier ?
En gros pour quel volume il est intéressant de resubdiviser ?

 
Ya (indirectement) un peu de réflexion autour de ça ici : http://www.w3.org/Provider/Style/URI
Ça peut ptet t'intéresser...

C'est à dire ?

ce que propose nazztaz

si l'utilisateur mets a jour un fichier, ou le renomme, tu dois le déplacer. Perso , je préfère séparer complètement le stockage physique de l'affichage  
 
pour les 2 profondeurs, ça me semble aussi une bonne estimation

Et le hachage permet d'avoir une certaine uniformité de la répartition, chose que tu n'as pas si tu tries simplement sur un nom de fichier.

Ici c'est l'élite hautaine et méprisante, donc tu t'adaptes ou tu te casse

le grand complot mondial de l'élite des programmeur qui veut cacher ses screenshots de plantages au monde

PQ

Boom ?

Moi j'ai aimé

ça dépends du type de fichier et de ce qui fait goulet d'étrangelement.

on est d'accord

et sinon, id % nombreDeRepsQueTuVeux, ca marche aussi... Pourquoi un sha ?

 
Comme dit mareek, ça dépend de ce qui est lent : la compression ou la transmission sur le réseau ?
Sachant que gzip permet de très bons compromis vitesse/compression.

okay
 
 
sha 1, c'est quoi ?
La première subdivision se fait avec le premier charactère. La seconde avec le second ?
 
Pour quel volume de fichier (nb/taille) on a un impact ?

Ouai, ça c'est déjà en place chez nous

 
Fig 1: Windev