Salut
 
1- Je veux stocker du texte (des articles pour une sorte de journale en ligne), potentiellement assez long. Je voulais d'abord utiliser ma base mysql pour ca, mais je me souviens avoir eu une fois -quand j'étais complètement débutant- des problèmes des problème de taille (requete trop longue et ce genre de choses). J'me suis donc dit, tu vas passer simplement par des fichiers textes. Est-ce une bonne idée ?
 
2-Concernant la gestion des droits d'accès aux fichiers, je me pose quelques questions. Pour l'instant, je n'ai pas eu vraiment de problèmes en local, mais j'essaye d'anticiper le passage chez l'hébergeur. Toujours pour mes articles, je stocke des photos et autres docs. Pour ca, je crée un répertoire pour chaque article (mkdir). Comment ca va se passer sur l'hébergeur ? y'a besoin de chmoder qq chose pour que ca marche ? Ensuite, j'ai lu qu'il fallait avoir les droits pour écrire un fichier texte. Je fais comment pour que ca soit géré dynamiquement (quand quelqu'un poste un nouvel article...)
 
Voila, merci d'avance

1 - non, trés mauvaise idée, c'est un bordel pas possible à gérer, pour ton probleme de taille de requetes, ca serait plutot un probleme de type de champ de tes tables, pour un long texte il y'a des types adaptés suivant le nombre et le type de données.
 
2 - idem pour tes articles, faire des dossiers c'est chiant et plus compliqué que d'utiliser une bdd avec un dossier stockant toutes les images.
 
 
Sinon pour les dossiers et fichiers, quand j'ai un probleme de droits d'accés dans mes scripts, je teste en ajoutant petit à petit des droits jusqu'a que ca fonctionne (parfois je suis obligé de mettre un 777 alors que c'est le serveur qui écrit le fichier, j'ai pas trés bien compris ca )

1/ Je veux bien que ce soit un mauvaise idée, c'est même pour ca que je pose la question. Mais pourquoi ?  
Sinon en gros tu me dis que si j'ai un énorme(enfin gros) champ de saisie, si je le balance à Mysql comme ca, y'aura pas de problème à condition que j'ai choisi le bon type ?
 
2-  
Ensuite, j'ai fait une très courte recherche sur le stockage d'img dans un bdd, et un des premiers trucs à sortir sous google c'est un post d'harkonnen :  
Harkonnen    
La performance avant tout   Posté le 04-03-2004 à 12:10:25                              
 
pourquoi mettre une image directement dans la BDD ?    
ça alourdit la base, le traitement, c'est impropre au possible. tu ferais mieux de stocker le chemin vers ces images.
 
 
Donc pas d'img ds la bdd. Ce qui laisse toujours mon pb de droits d'accès à créer au fur et à mesure. Sinon je vais être réduit à balanceer toutes les images, vidéos et flash dans un même répertoire ce que j'essaye d'éviter...

 
Et il a raison, les types blob ne sont pas fait pour ça...
 
Quels droits d'accès ? dans le cas d'une image, tu stockes son chemin d'accès et tu les utilises dans des balises <a>, ce ne sont pas des fichiers que tu ouvres, fermes et manipules en php (ceux qui eux ont des droits d'accès à gérer).
 
Je gère tous les jours (bon, pas chez des hébergeurs "standards" ) des sites de publications "en mode web", et je n'utilises des fichiers textes que pour un système de cache, pas pour abriter les données brutes. Quand à un problème de requête trop longue, c'est plus lier à un type de champs mal adapté ou à une structure de base mal pensée

Ok merci pour css précisions. Les droits d'accès c'était pour les fichiers textes...Mais vu qu'ils ont pas lieu d'exister, plus de problème .
 
>>une structure de base mal pensée
Comment ca ?

 
Bon, un exemple parmis d'autre :
 
Un article se compose de (1..n) paragraphes d'ac ? j'ai déjà vu certaines personnes mettre tous les paragraphes dans le même champs de la bd plutôt que de créer une table paragraphe et une liaison (ce qui permet par exemple de limiter le nombre de paragraphes affichés sur une page et ainsi d'éviter d'avoir des pages de 11 écrans de long <- véridique)

Certaines personnes...Tu veux dire moi non ?  
Trois questions (désolé):
-Les paragraphes sont d'une longueur variable evidemment, si tu fixes par exmple la limite à 5 paragraphes par page, et que celui qui envoie l'article fait des paragraphes de deux lignes, tu auras 10 lignes dans la page...Tu gères comment ca ?
-Pour la saisie, tu utilises un seul textarea et tu repères les \n right ?
-La liaison, tu la fait avec un champ enum dans l'article ?
 
Merci

 
Non, pas spécialement, je l'ai déjà vu chez des gens plus "professionnel" (ou qui se disaient pros   )
 

 
1. Ca dépend, on a déjà utilisé diverses méthodes : permettre à l'encodeur de préciser si un paragraphe peut ou non commencer une page (pour éviter de se retrouver avec un paragraphe de 2 lignes seul sur la page ), baser l'affichage non pas sur le nombre de paragraphe mais sur leurs tailles (par exemple dire "on affiche un paragraphe complet jusqu'à ce que la taille totale des paragraphes affichés > 10000 chars) ou même vérifier la taille à l'encodage et "concatener" des paragraphes trop petit (qui n'en font plus qu'un dans la bd, on a utilisé ça avec la première méthode). Mais bon, c'est globalement des prises de têtes pour pas grand chose
 
2. Ah non, sûrement pas le /n, t'aurais que des paragraphes d'une ligne alors . On a deux grosses méthodes : soit créer un textarea par paragraphe soit utiliser une convention (par exemple une ligne blanche => changement de paragraphe) pour les détecter dans un seul textarea, ça varie suivant le projet et les cas.
 
3. Non, c'est une simple liaison clé unique pour l'article > clé étrangère pour le paragraphe avec un numéro pour l'ordre des paragraphes

1-Ok merci pour les idées, je verrais ca quand tout l reste marchera
2-C'est ça que je voulais dire repérer les \n\n pas les \n
3-Ah ben oui c mieux
 
Bon ben c'est niquel, merci beaucoup pour tes explications/idéees et ta patience. Maintenant, au boulot !