Discussion :

[ptilemare]

Bonjour à tous !

Je suis face à un dilemme. Je fais un projet (personnel) de création de rapports en ligne. Quelques mots sur le pourquoi du comment : Tout simplement car il faut que je me remette au PHP, et je travaille avec des gens qui sont au Mexique, et un peu en Europe centrale. Avoir des rapports à rédiger ( textuellement, pas de mise en page ) avec des gens qui ne sont pas là est assez difficile à faire. On a jamais la bonne version du rapport, on bosse sur les mêmes parties du truc, bref !

Mon problème est le suivant. Je ne sais quelle décision prendre. Pour stocker une paragraphe d'un rapport rédigé en ligne, vaut-il mieux :

- stocker le paragraphe dans un champs texte immense
- stocker le paragraphe dans un fichier qu'on upload sur la base mysql
- stocker le paragraphe dans un fichier texte sur serveur, et stocker dans la base le chemin vers le fichier

??? Quels seraient les avantages/inconvénients de chaque méthode, d'apres vous ? J'imagine qu'il n'existe pas une seule bonne méthode mais je souhaite en savoir un peu plus sur chacune, si quelqu'un a déjà été confronté à ce choix. Et si d'autres options sont possibles, je ne sais pas, je ne pense pas à tout

Merci à vous tous !

[Benjamin Delespierre]

Je vais essayer d'apporter des éléments de réponse:

- stocker le paragraphe dans un champs texte immense

Avantages: la recherche fulltext, sauvegarde du modèle facilité
Inconvénients: charge mémoire sur la base (seulement si tes paragraphes sont très volumineux)

- stocker le paragraphe dans un fichier qu'on upload sur la base mysql

Avantages: Nul
Inconvénient: pas de recherche possible, charge inutile des transferts entre PHP et MySQL

- stocker le paragraphe dans un fichier texte sur serveur, et stocker dans la base le chemin vers le fichier

Avantage: aucune charge sur la base
Inconvénient: difficulté de lier les entrée BDD à leurs ressources sur le serveur, impossible d'exporter la base sans répliquer également les fichiers manuellement


Si ce que tu as à persister constitue des données plain/text, ce n'est pas vraiment la peine de se poser la question: mets des champs TEXT dans les tables.
Pour ton problème de parallélisme des édition, tu peux utiliser les verrous fichiers (floc) ou les verrous sur les tables pour empêcher deux utilisateurs d'être en collision sur une ressource.

[ptilemare]

Merci pour les explications. Si d'autres personnes souhaitent compléter ceci, je ne vais pas mettre le tag résolu de suite, histoire de voir des avis différents !

En ce qui concerne ces paragraphes, leur taille ira d'une trentaine de mots à quelques centaines. Rien d'excessif, c'est pas pour rédiger des thèses complètes. Mais ça vaut quand même le coup de se poser la question du stockage. Au niveau utilisateurs, je prévois pour une dizaine en simultané, rien de bien excessif non plus. Je referai une étude si je souhaite vraiment le rendre plus volumineux.

Je n'avais pas du tout pensé au verrouillage des tables ! Juste à un champ booléen ( "blocage" ) qui serait modifié à chaque fois qu'un utilisateur souhaiterait modifier un paragraphe en fait, et qu'on testerait pour permettre ou non une édition. Je vais me pencher sur les verrous

[CinePhil]

Effectivement, pour des paragraphes ne dépassant pas quelques centaines de mots, inutile de s'encombrer de fichiers en parallèle à la BDD.
Par contre, si ces paragraphes sont nombreux, pour améliorer les performances, il peut être judicieux d'isoler ces paragraphes dans une table séparée des autres caractéristiques des paragraphes.

MCD :
paragraphe -1,1----Contenir----(1,1)- Texte_paragraphe

Tables :
paragraphe (prg_id, prg_titre, prg_version, prg_id_etat...)
texte_paragraphe (tpg_id_paragraphe, tpg_texte)

Ainsi, on n'interroge la table texte_paragraphe que lorsqu'on veut vraiment récupérer le texte du paragraphe et on ne se trimballe pas le gros volume de données représenté par ces textes lorsqu'on veut seulement afficher la liste des paragraphe, gérer leur version, leur validation...

Mais ce ne sera sensible qu'à partir d'un assez gros volume de données.

[ptilemare]

Intéressant ! Merci pour l'avis !

Cependant, si je ne souhaite pas me trimballer le volume de données au niveau requêtes, n'ai-je pas juste à éviter des requêtes de type SELECT * pour ne pas avoir à trimballer mon paragraphe mais seulement les champs de la table paragraphe qui m'intéressent ?

Je pense en effet qu'il y aura de nombreux paragraphes.

[Invité]

BOjnour,
a priori, tu as juste besoin d'un champ dans ta BD où stocker les paragraphes :

- CHAR : une chaîne de caractères de taille fixée (de 1 à 255 caractères)
- VARCHAR : une chaîne de caractères de taille variable (de 1 à 255 caractères)
- TINYTEXT ou TINYBLOB : un objet BLOB ou TEXT ayant une longueur maximale de 255 caractères
- TEXT ou BLOB : un objet BLOB ou TEXT ayant une longueur maximale de 65 535 caractères
- MEDIUMTEXT ou MEDIUMBLOB : un objet BLOB ou TEXT ayant une longueur maximale de 16 777 215 caractères
- LONGTEXT ou LONGBLOB : un objet BLOB ou TEXT ayant une longueur maximale de 4 294 967 295 caractères

[ptilemare]

Merci pour la description des types
Cependant, pour la structure de la base, dois-je faire comme Cinephil a indiqué ?
Dois-je séparer les informations sur le paragraphe du paragraphe lui même ou bien éviter les requêtes de type SELECT * suffirait à éviter le transit ?