Je suis en train de monter une base (site php/MySQL) où le client pourra archiver ses documents et je viens d'apprendre qu'une bonne partie des documents approcheront les 8mo voir 10mo ...  
Je partais sur l'upload par http post (classique), qui me permettait de renommer mon fichier comme je le voulais afin de faire un lien entre la fiche dans la base MySQL et le fichier ...
Mais vous vous rendez compte que pour un tel poids, ça ne passera jamais de cette manière ... Est-ce que vous l'avez déjà fait ?
 
Précisions :  
- Ce n'est pas pour uploader un fichier unique mais des fichiers différents à chaque fois dont le nom sur le serveur sera généré par php (à la limite, ça, je pourrais éventuellement m'en passer en mettant le nom du fichier direct dans la base mais c'est surtout pour préciser que cet upload ne concerne pas un seul fichier)
- Je suis sur un serveur pro mais mutualisé, donc, je n'ai pas accès (du moins dans l'immédiat) aux configurations d'apache.
 
Topheee

ah?

la taile maxi est gérée par un variable du php.ini
"upload_max_filesize"
cette valeur est autour de 2MO (en tout cas en réglage de base  easyPHP 1.7), à savoir si tu peux l'augmenter via ini_set... ou si tu peux éditer ton php.ini

je fais des upload via HTTP de 20 Mo et ca marche tres bien (je suis en ASP .net) Et je stock ca sous formes de Blob dans une base SQL Server... Vois pas le probleme avec la taille (la limite en ASP est de 4 Mo mais ca se modifie dans les fichiers de config (machine.config ou web.config))...

En effet ca risque de poser probleme, et pour diverses raisons :
Par defaut, la taille maximale qu'accepte php pour un fichier transmis par post est de 2M.
Meme si tu arrive a changer cette valeur, ensuite vient le probleme du "timeout". En effet, l'envoi d'un tel fichier risque de prendre du temps, et en fonction de certains navigateurs, ces derniers risquent de penser que le serveur est inaccesible, et faire un timeout (je pense a IE notament, temps max de chargement de la page 30 sec ou 5 min je sais plus).
 
Donc le probleme va venir de la vitesse d'upload du visiteur. Si ce dernier a une vitesse elevee, ca ne posera pas trop de probleme. En revanche plus sa vitesse sera faible, plus il lui faudra du temps pour uploader le fichier, donc plus il y aura de risques de timeout...

Il me semble pas qu'il peut y avoir de problème de timeout puisque le navigateur fait quelquechose, en l'occurence il envoie les données.

logiquement c'est po le navigateur qui fait timeout, lui il ne fait que renvoyer l'erreur du serveur qui reçoit les données...

Timeout du script php sur le serveur.

aucun rapport
l'envoy du fichier résulte du protocole http.
une fois le transfert trerminé, la page du champs "action" du formulaire reprend le relais (page php en l'occurence)
tout se passe alors sur le serveur.
et si vraiment ton script est succeptible de mettre plus de 30 secondes a s'executer, bin tu modifies le temps max via ini_set et tu préviens l'utilisateur...

 
ah oui...
Comme quoi on peut très bien dire des conneries en mangeant!

toi aussi t'es monoprocessus...

Par contre il faut augmenter ceci je pense :
http://fr.php.net/manual/en/ref.in [...] input-time

 
C'est bien crade de "stocker" des fichiers directement dans une base de données, la solution des fichier referencés dans une table MySQL avec leurs description me semble bien plus propre.
 
Sinon pour répondre au topic c'est effectivement une histoire de paramètres de PHP.
Tu fera attention au fait qu'il y a aussi un timeout sur Apache qui peut poser problème pour des uploads trés longs.

ca depend, si tu veux restreindre l'acces les donnée en blog peuvent etre utiles...

J'ai touché au timeout et je vais voir avec mon hébergeur s'il peut pas m'augmenter un peu le "upload_max_filesize" et le "post_max_size" ...
 
Merci pour vos réponses ...
 
Topheee

 
Pas forcément, tout dépend du cahier des charges :
 
Avantage du stockage en blob :
 
-Centralisation des données sur un seul serveur (pas besoin d'un serveur de fichiers en plus) -> Facilité de backup (moins de risque de perdre des fichiers en route...)
 
-Gestion de la sécurité plus facile (on ne peut accéder au contenu de la base (et donc des fichiers) qu'a travers l'application), alors qu'un serveur de fichier, il faut bien le configurer et cela pose souvent probleme (coût) aux DSI...
 
-Pas de probleme de nommage des fichiers (on stocke le contenu dans un blob et le nom dans un varchar), tandis que si on utilise un serveur de fichier, comment on stocke si 2 fichiers ont le meme nom ? On les renomme ? Si oui, comment on garde le nom du fichier d'origine ? Dans la base de données ? C'est pas tres propre non plus, on se retrouve avec des noms completement foireux a base de Guid...
 
-Les fichiers étant en base, pas de propagation possible de virus lors du stockage (alors que sur un serveur de fichier, on peut les executer et si ca arrive ca peut véroler tout les autres fichiers... Dans un blob, ca ne risques pas d'arriver...)
 
Bref, tu le vois, ce n'est pas aussi "évident" que cela pourrait paraitre...