Tutoriel et bdd : besoin de conseils experts!
Résolu
clR
-
5ClR Messages postés 3 Date d'inscription Statut Membre Dernière intervention -
5ClR Messages postés 3 Date d'inscription Statut Membre Dernière intervention -
Bonjour,
je débute en php et mysql et je cherche à faire une base de données de tutoriels.
je ne sais pas vraiment quelle est la meilleure façon de s'y prendre.
j'ai pensé à deux choses : soit remplir ma bdd avec un champ de texte mis en page, soit faire un lien vers des docs pdf, autant qu'il y aurait de tuto.
Deux choses me dérangent dans ces deux méthodes :
la première prendrait bcp de place je crois, quant à la seconde, elle ne m'enchante pas d'avance pour le manque de fluidité dans les manipulations.
Je peux aussi faire autant de page html qu'il y aura de tuto mais ça m'ennuie...
Auriez-vous un/des conseils pour tendre vers des tutoriaux utilisables comme ceux du site du zéro?
merci d'avance et bonne journée à tous !
je débute en php et mysql et je cherche à faire une base de données de tutoriels.
je ne sais pas vraiment quelle est la meilleure façon de s'y prendre.
j'ai pensé à deux choses : soit remplir ma bdd avec un champ de texte mis en page, soit faire un lien vers des docs pdf, autant qu'il y aurait de tuto.
Deux choses me dérangent dans ces deux méthodes :
la première prendrait bcp de place je crois, quant à la seconde, elle ne m'enchante pas d'avance pour le manque de fluidité dans les manipulations.
Je peux aussi faire autant de page html qu'il y aura de tuto mais ça m'ennuie...
Auriez-vous un/des conseils pour tendre vers des tutoriaux utilisables comme ceux du site du zéro?
merci d'avance et bonne journée à tous !
A voir également:
- Tutoriel et bdd : besoin de conseils experts!
- Tutoriel onedrive - Guide
- Tutoriel tableau croisé dynamique - Guide
- Franceconnect créer compte tutoriel - Guide
- Rufus tutoriel windows 11 - Guide
- Tutoriel signature électronique - Guide
8 réponses
Re-salut !
Les vrais codeurs, comme je disais, trouvent un équilibre entre les fichiers et les BDD. En gros, ce que tu mets dans ta BDD, c'est l'information qui aura besoin d'être changée. Toute l'information qui est là pour rester, tu perdrais ton temps à le mettre dans ta BDD et à te donner le trouble d'aller la chercher à chaque fois.
Donc en gros, l'info statique dans les fichiers .php, le contenu dynamique dans la BDD.
Dans les BDD, tu peux mettre des balises HTML. Oui, les champs "text" ont une limite de grosseur, mais c'est assez monstrueux. À titre de référence, il existe quatre types de cellules de contenu comparables : TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT :
TINYTEXT : ~255 caractères maximum ;
TEXT : ~65500 caractères maximum ;
MEDIUMTEXT : ~16777000 caractères maximum ;
LONGTEXT : ~4295000000 caractères maximum ;
(Noter que c'est très arrondi, mais ça donne une idée).
Et quand je parle d'optimiser la base, oui les types de champ sont importants. On a beau dire que l'espace est "cheap" ces temps-ci avec les ordinateurs et les connexions de plus en plus rapides, un peu d'optimisation peut donner d'énormes gains quand il s'agit d'une grosse BDD. Donc entre autres, n'utilise pas de LONGTEXT quand un MEDIUMTEXT suffirait. Surtout quand on débute, on a tendance à être parano et à vouloir s'assurer d'avoir de l'espace, mais c'est un mauvais réflexe, il vaut mieux y penser soigneusement et être réaliste.
Aussi, il faut optimiser les requêtes. Si un jour tu prévois avoir une table de quelques millions d'entrées, et que pour une requête donnée tu as besoin d'environ 10 résultats, il y a des moyens de mieeux cibler ta recherche, par exemples avec des sous-requêtes, afin de ne pas chercher inutilement à travers des millions de possibilités qui d'entrée de jeu ne conviennent pas à la recherche effectuée. Mais ça, c'est des considérations assez avancées, et tu pourras t'en soucier quand tu auras effectivement plusieurs dizaines de milliers d'entrées dans ta BDD. En-dessous de 10,000 entrées dans une table, je pense (très personnellement) que ça ne vait pas le coup de mettre trop de ressources à optimiser les requêtes.
Comme je dis, les BDD ne sont pas mon domaine de prédilection (encore !) donc si quelqu'un veut ajouter son grain de sel, ne vous gênez surtout pas ! Mais je crois bien que c'est suffisant pour tes besoins.
Les vrais codeurs, comme je disais, trouvent un équilibre entre les fichiers et les BDD. En gros, ce que tu mets dans ta BDD, c'est l'information qui aura besoin d'être changée. Toute l'information qui est là pour rester, tu perdrais ton temps à le mettre dans ta BDD et à te donner le trouble d'aller la chercher à chaque fois.
Donc en gros, l'info statique dans les fichiers .php, le contenu dynamique dans la BDD.
Dans les BDD, tu peux mettre des balises HTML. Oui, les champs "text" ont une limite de grosseur, mais c'est assez monstrueux. À titre de référence, il existe quatre types de cellules de contenu comparables : TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT :
TINYTEXT : ~255 caractères maximum ;
TEXT : ~65500 caractères maximum ;
MEDIUMTEXT : ~16777000 caractères maximum ;
LONGTEXT : ~4295000000 caractères maximum ;
(Noter que c'est très arrondi, mais ça donne une idée).
Et quand je parle d'optimiser la base, oui les types de champ sont importants. On a beau dire que l'espace est "cheap" ces temps-ci avec les ordinateurs et les connexions de plus en plus rapides, un peu d'optimisation peut donner d'énormes gains quand il s'agit d'une grosse BDD. Donc entre autres, n'utilise pas de LONGTEXT quand un MEDIUMTEXT suffirait. Surtout quand on débute, on a tendance à être parano et à vouloir s'assurer d'avoir de l'espace, mais c'est un mauvais réflexe, il vaut mieux y penser soigneusement et être réaliste.
Aussi, il faut optimiser les requêtes. Si un jour tu prévois avoir une table de quelques millions d'entrées, et que pour une requête donnée tu as besoin d'environ 10 résultats, il y a des moyens de mieeux cibler ta recherche, par exemples avec des sous-requêtes, afin de ne pas chercher inutilement à travers des millions de possibilités qui d'entrée de jeu ne conviennent pas à la recherche effectuée. Mais ça, c'est des considérations assez avancées, et tu pourras t'en soucier quand tu auras effectivement plusieurs dizaines de milliers d'entrées dans ta BDD. En-dessous de 10,000 entrées dans une table, je pense (très personnellement) que ça ne vait pas le coup de mettre trop de ressources à optimiser les requêtes.
Comme je dis, les BDD ne sont pas mon domaine de prédilection (encore !) donc si quelqu'un veut ajouter son grain de sel, ne vous gênez surtout pas ! Mais je crois bien que c'est suffisant pour tes besoins.
Bonjour !
Je pense que tu n'auras pas tellement le choix, la manière la plus efficace est de trouver un juste milieu entre plusieurs pages html/php et du contenu entreposé dans la BDD.
Maintenant, si tu débutes, peut-être que tu auras de la difficulté à trouver ce juste milieu, c'est beaucoup une question d'adaptation au projet et de préférences personnelles ; le type de chose que seule l'expérience enseigne !
Une chose de sûre, je déconseille ton idée de fichiers PDFs. Tu l'as dit toi-même, c'est très restrictif, et c'est lourd en plus. ET c'est très mauvais pour faire des recherches rapides.
Ne te soucie pas de la grosseur de la base de données. Le tout sera seulement de l'optimiser à mesure que ton site va grandir. Quand une page a besoin d'une dizaine d'éléments dans la BDD, la plupart du temps elle s'en fout qu'il en existe des millions en tout parmi lesquels chercher, si c'est bien optimisé encore une fois. Mais à voir ton concept de site, je ne pense pas qu'elle devienne monumentale ;-)
Je pense que tu n'auras pas tellement le choix, la manière la plus efficace est de trouver un juste milieu entre plusieurs pages html/php et du contenu entreposé dans la BDD.
Maintenant, si tu débutes, peut-être que tu auras de la difficulté à trouver ce juste milieu, c'est beaucoup une question d'adaptation au projet et de préférences personnelles ; le type de chose que seule l'expérience enseigne !
Une chose de sûre, je déconseille ton idée de fichiers PDFs. Tu l'as dit toi-même, c'est très restrictif, et c'est lourd en plus. ET c'est très mauvais pour faire des recherches rapides.
Ne te soucie pas de la grosseur de la base de données. Le tout sera seulement de l'optimiser à mesure que ton site va grandir. Quand une page a besoin d'une dizaine d'éléments dans la BDD, la plupart du temps elle s'en fout qu'il en existe des millions en tout parmi lesquels chercher, si c'est bien optimisé encore une fois. Mais à voir ton concept de site, je ne pense pas qu'elle devienne monumentale ;-)
Bonjour Coeus !
Merci de ta réponse.
Bon finalement, tu me conseilles plutôt d'enregistrer du texte dans une bdd...
Du coup je pense m'y prendre comme ça :
1 tuto par entrée dans la base avec :
1 id unique, un champ titre, un champ date (et autres)...
et un champ (bien long) de contenus, qui serait mis en page directement dans la bdd (c'est ce champ de contenus qui me pose des pb...).
En fait, je dois pour ma boite créer un espèce de petit site en interne pour archiver toutes les procédures (qui peuvent être parfois très longues et qui sont au format papier, avec mise en page... un peu comme des tutos en somme).
Tu as du le remarquer déjà, ce n'est pas du tout mon corps de métier (mais je suis la moins pire semble t'il ici).Par contre quitte à faire qqch, j'aimerais réaliser, autant que faire se peut, un petit système bien pensé dès le départ.
Comment ils font les vrais codeurs ? Ils enregistrent des paragraphes ? On peut le faire directement avec tout un contenu (ce que je pense faire : ce serait plus pratique je crois...)?
Je crains que la longueur de ce champ de contenus (qui finirait bourré de balises html et autres pour la mise en page) ne me pose pb... ou que ça ne se fasse tout simplement pas comme ça...
D'ailleurs un champ est-il limité dans sa longueur ?
Et quand tu parles d'optimiser ma base, tu penses aux types des champs ?
Voilou plein de questions d'amateur !
Si jamais tu trouves le temps...
Et encore merci de tes conseils. Bonne aprèm
Merci de ta réponse.
Bon finalement, tu me conseilles plutôt d'enregistrer du texte dans une bdd...
Du coup je pense m'y prendre comme ça :
1 tuto par entrée dans la base avec :
1 id unique, un champ titre, un champ date (et autres)...
et un champ (bien long) de contenus, qui serait mis en page directement dans la bdd (c'est ce champ de contenus qui me pose des pb...).
En fait, je dois pour ma boite créer un espèce de petit site en interne pour archiver toutes les procédures (qui peuvent être parfois très longues et qui sont au format papier, avec mise en page... un peu comme des tutos en somme).
Tu as du le remarquer déjà, ce n'est pas du tout mon corps de métier (mais je suis la moins pire semble t'il ici).Par contre quitte à faire qqch, j'aimerais réaliser, autant que faire se peut, un petit système bien pensé dès le départ.
Comment ils font les vrais codeurs ? Ils enregistrent des paragraphes ? On peut le faire directement avec tout un contenu (ce que je pense faire : ce serait plus pratique je crois...)?
Je crains que la longueur de ce champ de contenus (qui finirait bourré de balises html et autres pour la mise en page) ne me pose pb... ou que ça ne se fasse tout simplement pas comme ça...
D'ailleurs un champ est-il limité dans sa longueur ?
Et quand tu parles d'optimiser ma base, tu penses aux types des champs ?
Voilou plein de questions d'amateur !
Si jamais tu trouves le temps...
Et encore merci de tes conseils. Bonne aprèm
Ok je ne m'inquiète pas alors.
Finalement donc pour résumer, j'aurais une page php nommée procédures, avec une en-tête et un pied, appelant diverses entrées de ma table.
chaque entrée comprend:
- un titre (nom de la procédure)
- un contenu (la procédure mise en page dans un champ text avec un type de cellule variable selon le nombre de caractères du dit contenu)
Pour ce qui est d'une requête "optimisée"... je pensais faire un select avec tous les champ "titre", récupérer l'id du champ titre sélectionné pour l'affichage du contenu de la procédure concernée dans le corps de la page.
(et je suis bien contente, ça ne me paraît pas si complexe que je l'aurais cru !)
Et oui effectivement je ne suis pas contre d'autres idées...
je mets quand même le sujet en résolu, car j'ai de bonnes pistes pour creuser.
Merci Coeus pour le plan et pour la pelle, ils me seront bien utiles
: )
Finalement donc pour résumer, j'aurais une page php nommée procédures, avec une en-tête et un pied, appelant diverses entrées de ma table.
chaque entrée comprend:
- un titre (nom de la procédure)
- un contenu (la procédure mise en page dans un champ text avec un type de cellule variable selon le nombre de caractères du dit contenu)
Pour ce qui est d'une requête "optimisée"... je pensais faire un select avec tous les champ "titre", récupérer l'id du champ titre sélectionné pour l'affichage du contenu de la procédure concernée dans le corps de la page.
(et je suis bien contente, ça ne me paraît pas si complexe que je l'aurais cru !)
Et oui effectivement je ne suis pas contre d'autres idées...
je mets quand même le sujet en résolu, car j'ai de bonnes pistes pour creuser.
Merci Coeus pour le plan et pour la pelle, ils me seront bien utiles
: )
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Pour résumer, ce que je te conseillerais :
- Une page d'index qui sera le "contenant" de ton site ;
- Une multitude de pages bien classées qui seront le contenant de chacune des sections, et qui renfermeront le contenu statique ;
- Chacune de ces pages a ses requêtes propres pour appeler son contenu dynamique de la BDD.
Et pour tes requêtes, ça va fonctionner, tu utilises la méthode standard, c'est parfait. Retourne consulter des experts le jour où tu auras des millions de pages, mais pour le moment c'est parfait ! ;-)
Bonne chance !!!
- Une page d'index qui sera le "contenant" de ton site ;
- Une multitude de pages bien classées qui seront le contenant de chacune des sections, et qui renfermeront le contenu statique ;
- Chacune de ces pages a ses requêtes propres pour appeler son contenu dynamique de la BDD.
Et pour tes requêtes, ça va fonctionner, tu utilises la méthode standard, c'est parfait. Retourne consulter des experts le jour où tu auras des millions de pages, mais pour le moment c'est parfait ! ;-)
Bonne chance !!!
Un doute m'assaille... peux-tu s'il te plait préciser....
"Une multitude de pages bien classées qui seront le contenant de chacune des sections, et qui renfermeront le contenu statique ;"
Qu'appelles-tu "section"?
Je pensais à quelque chose d'assez simple, du genre :
page d'index (contenant du site)
-----> contient en-tête
-----> corps de texte
-----> contient un select (de toutes les procédures)
-----> contient ma requête pour récupérer le titre & le contenu et l'affiche
-----> pied de page
"Une multitude de pages bien classées qui seront le contenant de chacune des sections, et qui renfermeront le contenu statique ;"
Qu'appelles-tu "section"?
Je pensais à quelque chose d'assez simple, du genre :
page d'index (contenant du site)
-----> contient en-tête
-----> corps de texte
-----> contient un select (de toutes les procédures)
-----> contient ma requête pour récupérer le titre & le contenu et l'affiche
-----> pied de page
Je pensais plus à, par exemple :
Avec l'arborescence de dossiers :
Est-ce que ça te paraît plus clair ?
[Page Index]
Contenant du <head> et du <body> pour tout le site (ou à peu près)
|
+-- [Dossier (Section) Accueil]
| |
| +-- [Page Index]
| | S'ouvre automatiquement dès qu'on entre dans la section Accueil
| | Contient : Requêtes SQL pour son propre contenu
| +-- [Page de nouvelles]
| | Contient : Requêtes SQL pour son propre contenu
| +-- [Page d'archives]
| | Contient : Requêtes SQL pour son propre contenu
|
+-- [Dossier PHP]
| |
| +-- [Page Index]
| | S'ouvre automatiquement dès qu'on entre dans la section PHP
| | Contient : Requêtes SQL pour son propre contenu
| +-- [Page de tutoriel 1]
| | Contient : Requêtes SQL pour son propre contenu
| +-- [Page de tutoriel 2]
| | Contient : Requêtes SQL pour son propre contenu
|
+-- [Dossier Javascript]
|
+-- [Page Index]
| S'ouvre automatiquement dès qu'on entre dans la section Javascript
| Contient : Requêtes SQL pour son propre contenu
+-- [Page de tutoriel 1]
| Contient : Requêtes SQL pour son propre contenu
+-- [Page de tutoriel 2]
Contient : Requêtes SQL pour son propre contenu
Avec l'arborescence de dossiers :
[www] | +-- [Contenu] | | | +-- [Accueil] | | | | | +-- Index.php | | +-- News.php | | +-- Archives.php | | | +-- [PHP] | | | | | +-- Index.php | | +-- Tuto1.php | | +-- Tuto2.php | | | +-- [Javascript] | | | +-- Index.php | +-- Tuto1.php | +-- Tuto2.php | +-- Index.php Contient des include() vers toutes les pages du dossier Contenu.
Est-ce que ça te paraît plus clair ?
J'édite ici la réponse que m'a faite Coeus, si ça peut aider qq'1 d'autre.
"Je pensais plus à, par exemple :
[Page Index]
Contenant du <head> et du <body> pour tout le site (ou à peu près)
|
+-- [Dossier (Section) Accueil]
| |
| +-- [Page Index]
| | S'ouvre automatiquement dès qu'on entre dans la section Accueil
| | Contient : Requêtes SQL pour son propre contenu
| +-- [Page de nouvelles]
| | Contient : Requêtes SQL pour son propre contenu
| +-- [Page d'archives]
| | Contient : Requêtes SQL pour son propre contenu
|
+-- [Dossier PHP]
| |
| +-- [Page Index]
| | S'ouvre automatiquement dès qu'on entre dans la section PHP
| | Contient : Requêtes SQL pour son propre contenu
| +-- [Page de tutoriel 1]
| | Contient : Requêtes SQL pour son propre contenu
| +-- [Page de tutoriel 2]
| | Contient : Requêtes SQL pour son propre contenu
|
+-- [Dossier Javascript]
|
+-- [Page Index]
| S'ouvre automatiquement dès qu'on entre dans la section Javascript
| Contient : Requêtes SQL pour son propre contenu
+-- [Page de tutoriel 1]
| Contient : Requêtes SQL pour son propre contenu
+-- [Page de tutoriel 2]
Contient : Requêtes SQL pour son propre contenu
Avec l'arborescence de dossiers :
[www]
|
+-- [Contenu]
| |
| +-- [Accueil]
| | |
| | +-- Index.php
| | +-- News.php
| | +-- Archives.php
| |
| +-- [PHP]
| | |
| | +-- Index.php
| | +-- Tuto1.php
| | +-- Tuto2.php
| |
| +-- [Javascript]
| |
| +-- Index.php
| +-- Tuto1.php
| +-- Tuto2.php
|
+-- Index.php
Contient des include() vers toutes les pages du dossier Contenu.
Est-ce que ça te paraît plus clair ?
"
avec un grand merci. Bien comprit.
"Je pensais plus à, par exemple :
[Page Index]
Contenant du <head> et du <body> pour tout le site (ou à peu près)
|
+-- [Dossier (Section) Accueil]
| |
| +-- [Page Index]
| | S'ouvre automatiquement dès qu'on entre dans la section Accueil
| | Contient : Requêtes SQL pour son propre contenu
| +-- [Page de nouvelles]
| | Contient : Requêtes SQL pour son propre contenu
| +-- [Page d'archives]
| | Contient : Requêtes SQL pour son propre contenu
|
+-- [Dossier PHP]
| |
| +-- [Page Index]
| | S'ouvre automatiquement dès qu'on entre dans la section PHP
| | Contient : Requêtes SQL pour son propre contenu
| +-- [Page de tutoriel 1]
| | Contient : Requêtes SQL pour son propre contenu
| +-- [Page de tutoriel 2]
| | Contient : Requêtes SQL pour son propre contenu
|
+-- [Dossier Javascript]
|
+-- [Page Index]
| S'ouvre automatiquement dès qu'on entre dans la section Javascript
| Contient : Requêtes SQL pour son propre contenu
+-- [Page de tutoriel 1]
| Contient : Requêtes SQL pour son propre contenu
+-- [Page de tutoriel 2]
Contient : Requêtes SQL pour son propre contenu
Avec l'arborescence de dossiers :
[www]
|
+-- [Contenu]
| |
| +-- [Accueil]
| | |
| | +-- Index.php
| | +-- News.php
| | +-- Archives.php
| |
| +-- [PHP]
| | |
| | +-- Index.php
| | +-- Tuto1.php
| | +-- Tuto2.php
| |
| +-- [Javascript]
| |
| +-- Index.php
| +-- Tuto1.php
| +-- Tuto2.php
|
+-- Index.php
Contient des include() vers toutes les pages du dossier Contenu.
Est-ce que ça te paraît plus clair ?
"
avec un grand merci. Bien comprit.
Pense maintenant qu'un champ TEXT peut contenir trois fois plus que ça, soit plus de 65000 caractères. Ça VA être assez ;-)
J'ai fait le test : un texte de 16 pages, écrit en Verdana 12 pts, me donnait environ 40,000 caractères. Pas pire, quand même !
Petit truc pour se rassurer !