Donc, ça signifie que tu as un contrôle exclusif (?) du code en question, ça écarte bien des soucis de sécurité.

Mais quant au stockage, je procèderais comme pour une image : stockage d'un fichier php indépendant d'une part, et stockage d'autre part en base d'éléments de références sur ce code. Comme ça, ta requête ne va récupérer que les références permettant de pointer sur le bon fichier. Et si tu ajoutes ce code via un formulaire dans une interface admin d'ajout de tutos, au moment d'enregistrer le code, tu crée directement le fichier.

L'idée, c'est que si la page est beaucoup demandée, il ne faut pas plomber les performances avec l'écriture du fichier à partir d'un code récupéré en base pour chaque visiteur. Quoique je garde une interrogation : contrôle exclusif ou bien les visiteurs pourront tester ledit code avec divers paramètre de leur choix ? Dans ce dernier cas, il faudra être quand même très prudent et filtrer sévèrement les entrées utilisateur, toujours pour des raisons de sécurité relativement évidentes.

Hello à vous
Cyrano dsl pour le retard de réponse mais j'avais un petit souci avec internet

Merci déjà pour vos réponses.

Enfait l'idée de départ c'est de créer un site tutoriel où je voudrai mettre en texte le code et juste en dessous le résultat du code pendant son execution.

Comme je souhaite mettre pas mal de petit bout de code comme ca je souhaite les intégrer en base de données pour que ce soit plus facile à gérer

Merci beaucoup

Ha ben pour du texte en revanche, il y a des fonctions native fort pratique dans MySQL pour la recherche. Une image, c'est du binaire et ça peut rapidement prendre des proportions indécentes en terme de volume occupé. On ne fait pas vraiment de recherche sur le code binaire de l'image elle-même en général, donc on stocke l'image à part et les informations qui la concernent dans la base.
Pour des documents textes, le problème est un peu différent et pour pouvoir bénéficier des fonctions de recherche SQL natives, il faudra le stocker, mais si c'est du PDF de 3000 pages, il sera peut-être plus rationnel de stocker le fichier PDF lui-même et d'utiliser un client PDF pour le lire et y faire des recherches, ou alors il faudrait exploser le fichier en chapitres et faire un stockage des textes avec un système de hiérarchie pour pouvoir si nécessaire reconstruire le fichier complet. Sans ça, on va avoir des performances assez piteuses à mon avis...

Les 2 conceptions se défendent
c'est la même problématique avec un champ "description" dans n'importe quelle base de données
si les utilisateurs peuvent saisir un texte très long, alors il peut être préférable d'enregistrer dans la base de données un pointeur de fichier au lieu du texte lui-même

« Qui peut le plus peut le moins »
Les différences de performance seraient certes presque non mesurables avec des petits bouts de code, mais la proportion gagnée serait la même quelle que soient leurs tailles : la conclusion est que selon l'option choisie, on privilégie les performances sans égard pour les tailles des bouts de codes, ou on prend le risque de voir certaines exécutions ramer un peu parce qu'un ou plusieurs de ces bouts de code deviennent vraiment importants.

Hé moileraz, c'est ton sujet, tu peux peut-être participer et éventuellement nous faire savoir si globalement on rejoint ton propos ou si on a dérapé complètement hors-sujet, ça s'est déjà vu sur PHPFrance

entièrement d'accord avec toi si la taille des bouts de code stockés est conséquente
mais si les bouts de code sont de petite taille, autant les mettre directement dans la base de données

Tout à fait d'accord... sauf pour ce qui est de stocker le code lui-même en base. C'est comme pour les images : on peut stocker toutes sortes de données concernant une image, mais on stocke le fichier lui-même en tant que fichier et non pas du binaire dans une base sans plomber les performances.
Et j'ajouterais même que rien n'interdit de pousser un poil plus loin en s'appuyant sur la base de données en intégrant une gestion d'ACL pour implémenter la question des droits que tu as évoqué à juste titre : mais on est toujours en PHP, la base ne stocke que des données qui permettent d'établir d'éventuels liens entre bouts de code et les droits associés.

Plutôt que de stocker le code lui-même en base lors de son enregistrement, on crée directement le fichier et en parallèle, on met en base de donnée les liens appropriés qui vont avec ce code. À l'exécution, le code étant déjà en fichier, on ne récupère que les paramètres en base et ensuite le fichier est directement exécutable. Si tu stockes le fichier en base, il faudra le ré-écrire à chaque fois qu'il doit être exécuté, globalement, ce sera beaucoup moins efficace.
Ou alors on ne crée le fichier que lorsqu'il est demandé mais une fois pour toute ? Quel intérêt ? C'est une étape supplémentaire au lieu de créer e fichier lors de son enregistrement initial...

La puissance du SQL ne serait pas pour le code stocké mais pour les caractéristiques associées
par exemple, si t'as 15 bouts de code stockés dans ta base de données
à chaque bout de code, tu associes des caractéristiques comme le nombre de fois qu'il a été exécuté, les personnes qui l'ont fait exécuter, la dernière fois qu'il a été exécuté, les personnes qui ont le droit de l'exécuter ...

Quelle puissance du SQL dans ce cas précis ? Stocker du code PHP ne permettra à aucun SGBD d'effectuer le moindre calcul dessus et encore moins de l'exécuter directement. Au mieux, à partir de certains critères de tris dans des requêtes un peu tordues il serait peut-être possible de construire différents code à partir des mêmes éléments : mais on fait ça beaucoup mieux directement en PHP avec des paramètres. À la rigueur on pourrait avantageusement stocker les valeurs possibles des paramètres dans une base, mais pas le code lui-même, ça me semble un contre-sens.

Le seul cas que j'arrive à voir où stocker du code PHP dans une base, c'est pour un site comme ici où on se contente de l'afficher ensuite dans des tutos, des exemples ou les messages des internautes, mais jamais ce code n'est exécuté.

Les traits peuvent effectivement être une bonne solution, tout dépend du besoin
mais tu n'as pas la puissance du SQL et ce n'est disponible qu'à partir de PHP 5.4.0

À ce compte là, je me tournerais vers les traits qui ont beaucoup plus d'avenir et surtout donneront des performances autrement plus significatives.

Quel intérêt dans ce cas de le stocker en base au lieu de l'enregistrer directement dans des fichiers à la bonne place comme faisant partie de l'application ?

par exemple, si le fichier généré est composé de plusieurs bouts de code.
Dans une table, tu stockes tous les bouts de code avec des caractéristiques associées.
Ensuite, qd tu génères ton fichier à inclure, tu sélectionnes les bouts de code que tu écris dans ton fichier
L'avantage d'une base de données dans tout ça, c'est que tu peux faire des requêtes sur les caractéristiques associées aux bouts de code

Quel intérêt dans ce cas de le stocker en base au lieu de l'enregistrer directement dans des fichiers à la bonne place comme faisant partie de l'application ?

- tu récuperes ton code de la base de données
- tu écris le code dans un fichier
- tu fais un include ou un require du fichier

Et tu blindes ton système à fond, parce que si le code stocké en base de donnée peut venir de n'importe qui, tu ouvres là une super faille de sécurité géante avec ce système, il ne faudra pas très longtemps à certains esprits un peu malveillants pour envoyer des codes destinés à transformer un peu tout le site, histoire de tout effacer ou encore d'organiser à partir de ton application un super-relai d'envoi de spam tous azimuts qui te pointerait toi comme expéditeur et non celui qui aura envoyé le code ...

justement, le code stocké dans la base de données ne vient peut-être pas (et même certainement pas) de n'importe qui ...

- tu récuperes ton code de la base de données
- tu écris le code dans un fichier
- tu fais un include ou un require du fichier

Et tu blindes ton système à fond, parce que si le code stocké en base de donnée peut venir de n'importe qui, tu ouvres là une super faille de sécurité géante avec ce système, il ne faudra pas très longtemps à certains esprits un peu malveillants pour envoyer des codes destinés à transformer un peu tout le site, histoire de tout effacer ou encore d'organiser à partir de ton application un super-relai d'envoi de spam tous azimuts qui te pointerait toi comme expéditeur et non celui qui aura envoyé le code ...