(Pseudo) base de données ?
Bonsoir,
J'ai un nouveau projet de dev, et celui-ci nécessite des trucs qui me semblent être "de l'ordre de" la base de données de petite à moyenne échelle mais j'aimerais vraiment faire ça avec PluXML alors j'essaie de voir si c'est jouable ou pas, et quelle stratégie privilégier.
En très gros, je cherche à faire un site d'informations sur un jeu vidéo. La plus grande partie du site consisterait en des pages présentant les différents personnages du jeu (et affichant tout un tas d'informations sur ces eux - donc on peut imaginer que chaque perso serait un record dans une base de données, avec une bonne trentaine de colonnes), et il y aurait aussi un système d'index permettant de faire des recherches et des filtrages sur ces informations pour trouver tel ou tel personnage.
Donc : j'ai une table "personnages", qui contient une trentaine de champs que j'ai besoin de pouvoir lire du côté PHP. Il y aura potentiellement d'autres tables, mais c'est celle là qui est la plus grosse (donc celle selon laquelle je calibre).
Au début j'ai envisagé de faire que sur chaque page de personnage, un champ (ajouté avec champArt - http://forum.pluxml.org/viewtopic.php?pid=51365) contienne une chaîne JSON contenant toutes les données (colonnes) du perso, lequel serait décodé à chaque fois que les données sont nécessaires... mais on parle de 200+ personnages, donc à mon avis c'est pas vraiment une bonne idée (je devine qu'on est dans la limite basse de ce qui "marche" en no-database).
Là je regarde vaguement SPXDATAS (http://forum.pluxml.org/viewtopic.php?id=4678) en me demandant si ça peut correspondre ou pas (je ne trouve pas la documentation...). Est-ce un genre de base de données à peu près optimisée et utilisable pour ce que je cherche à faire ?
Mon objectif serait de pouvoir, dans les pages d'index, lire les données de chaque personnage et en afficher certaines sans que le serveur tombe trop en miettes (donc : lire 200+ records). Les données changeront relativement rarement, donc il y a peut-être moyen de cacher l'opération, à voir (la page d'index est "juste" un très gros bout de HTML invariant que le lecteur manipule de son côté en JavaScript).
Sinon les deux autres options que j'envisage sont de travailler avec une vraie base de données juste pour gérer cet aspect du site (est-ce que PluXML peut coexister avec une base de données ?), ou bien au pire de carrément aller sur un autre CMS en dernier recours...
Résumé des options :
- Stocker les données des personnages dans des chaînes JSON se trouvant sur leurs pages (chaque personnage a un article lui correspondant), décodées à chaque lecture.
- Stocker les données dans une pseudo-database (SPXDATAS, peut-être - je ne suis pas certaine que ce soit bien de ça qu'il s'agit).
- Stocker les données dans une vraie database et interagir avec elle depuis PluXML.
- Essayer de trouver un CMS à database pas trop lourd.
(Le but ultime étant de pouvoir lire $CHARACTERS[RON][AGE] ou quelque chose d'équivalent pour afficher l'âge du personnage s'appellant Ron, par exemple.)
Opinions ?
J'ai un nouveau projet de dev, et celui-ci nécessite des trucs qui me semblent être "de l'ordre de" la base de données de petite à moyenne échelle mais j'aimerais vraiment faire ça avec PluXML alors j'essaie de voir si c'est jouable ou pas, et quelle stratégie privilégier.
En très gros, je cherche à faire un site d'informations sur un jeu vidéo. La plus grande partie du site consisterait en des pages présentant les différents personnages du jeu (et affichant tout un tas d'informations sur ces eux - donc on peut imaginer que chaque perso serait un record dans une base de données, avec une bonne trentaine de colonnes), et il y aurait aussi un système d'index permettant de faire des recherches et des filtrages sur ces informations pour trouver tel ou tel personnage.
Donc : j'ai une table "personnages", qui contient une trentaine de champs que j'ai besoin de pouvoir lire du côté PHP. Il y aura potentiellement d'autres tables, mais c'est celle là qui est la plus grosse (donc celle selon laquelle je calibre).
Au début j'ai envisagé de faire que sur chaque page de personnage, un champ (ajouté avec champArt - http://forum.pluxml.org/viewtopic.php?pid=51365) contienne une chaîne JSON contenant toutes les données (colonnes) du perso, lequel serait décodé à chaque fois que les données sont nécessaires... mais on parle de 200+ personnages, donc à mon avis c'est pas vraiment une bonne idée (je devine qu'on est dans la limite basse de ce qui "marche" en no-database).
Là je regarde vaguement SPXDATAS (http://forum.pluxml.org/viewtopic.php?id=4678) en me demandant si ça peut correspondre ou pas (je ne trouve pas la documentation...). Est-ce un genre de base de données à peu près optimisée et utilisable pour ce que je cherche à faire ?
Mon objectif serait de pouvoir, dans les pages d'index, lire les données de chaque personnage et en afficher certaines sans que le serveur tombe trop en miettes (donc : lire 200+ records). Les données changeront relativement rarement, donc il y a peut-être moyen de cacher l'opération, à voir (la page d'index est "juste" un très gros bout de HTML invariant que le lecteur manipule de son côté en JavaScript).
Sinon les deux autres options que j'envisage sont de travailler avec une vraie base de données juste pour gérer cet aspect du site (est-ce que PluXML peut coexister avec une base de données ?), ou bien au pire de carrément aller sur un autre CMS en dernier recours...
Résumé des options :
- Stocker les données des personnages dans des chaînes JSON se trouvant sur leurs pages (chaque personnage a un article lui correspondant), décodées à chaque lecture.
- Stocker les données dans une pseudo-database (SPXDATAS, peut-être - je ne suis pas certaine que ce soit bien de ça qu'il s'agit).
- Stocker les données dans une vraie database et interagir avec elle depuis PluXML.
- Essayer de trouver un CMS à database pas trop lourd.
(Le but ultime étant de pouvoir lire $CHARACTERS[RON][AGE] ou quelque chose d'équivalent pour afficher l'âge du personnage s'appellant Ron, par exemple.)
Opinions ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Tu trouveras des explications ici : http://www.secretsitebox.fr/blogspx/categorie6/spxdatas
et davantage encore dans le fichier d'aide inclus dans le plugin, dont la dernière version est téléchargeable ici.
D'accord, merci. Je vais lire ça tranquillement, ça a effectivement l'air de pouvoir faire l'affaire.
C'est la voie royale pour filtrer, trier, fusionner et n'afficher que les colonnes qui vont bien.
Tu peux stocker ta base de données dans le dossier data.
Pour ceux qui l'ignorent SQLITE3 stocke ses données dans un seul fichier.
Tu seras peut-être obligée d'écrire un plugiin sans que cela aille chercher bien loin.
On pourrait très bien utiliser à la place un unique fichier XML et faire des requêtes avec XPATH mais j'ai une préférence pour SQL que je maitrise mieux
A noter que PluXml fait un usage très très basique de XML.
Comme beaucoup j'attends toujours l'adoption de SimpleXml mais comme Sœur Anne nous ne voyons rien venir.
Si ton site n'évoluera pas beaucoup, peut-être envisager un générateur de site statique. C'est dans l'air du temps et cela commence à me titiller.
Cela demandera moins de ressources à ton hébergeur (Github ?).
J'utilise de temps en temps JSON pour pallier les limitations de PluXml en XML, notamment dans le cas des paramètres en tableaux et c'est assez facile avec les fonction json_encode et json_decode.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Static site, a priori je préfère éviter. Si la partie "base de données" va relativement peu changer (il s'agira surtout d'ajouter des entrées pour suivre les sorties de nouveaux personnages et autres changements in-game), il y aura une partie "articles, analyses" à côté qui elle risque d'être beaucoup plus dynamique. Le but du jeu étant d'avoir un truc à la fois facile à mettre à jour côté data, et facile à mettre à jour côté articles.
Merci pour l'information re: SQLITE3, je vais aller voir ça. Je dois admettre que "tant qu'à faire", je suis un peu plus excitée par l'idée d'apprendre ça plutôt que PLXDATAS vu que SQLITE3 semble utilisable un peu partout.
(json_encode et json_decode était la stratégie que j'envisageais au début, mais là ça me semble vraiment pas pratique, il y a juste trop de pages interconnectées à gérer.)
Un peu de lecture pour les indécis article un peu vieux SQLite est en version 3.19.3 sur la dernière release d'Ubuntu.
Cela va te faire une bonne révision de SQL
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Mais bon, si la machine est partie avec une des saveurs de SQL, on verra le résultat. C'est ce qui compte, après tout.
La base tient en un seul fichier. S'il n'existe pas, il se crée automatiquement et on envoie à SQLite3 un script dans un langage simple comme SQL pour créer toutes les tables dont on a besoin avec les tris nécessaires et les liens entre les tables alors qu'l semble qu'avec ce plugin il faille créer pas mal de dossiers et sous-dossiers.
Et si en cours de projet, on s'aperçoit qu'il manque une colonne à une table, on peut la rajouter simplement et sans risque, même s'il y a déjà beaucoup de données renseignées.
SQL est un langage tout à fait standard. On peut l'employer sur ce projet avec PluXml, comme dans d'autres projets sans PluXml. C'est universel.
Il existe déjà des éditeurs pour rentrer les données en local.
Si on a déjà des données disponibles dans des fichiers CSV, c'est un jeu d'enfant de les intégrer avec SQLite3
Bien sur cela a un coût. Il faut connaitre un minimum SQL. Mais étudier ce plugin aussi avec un retour sur investissement faible limité à PluXml.
Même si la personne n'a pas touché SQL depuis longtemps, le langage est tellement standardisé que ses réflexes vont revenir vite et qu'elle n'aura aucun souci à trouver de l'aide ici ou ailleurs.
Franchement si on connait SQL, c'est la voie royale pour gérer les données.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Je Pluxois bazooka07
SQLite3 est un excellent complement à PluXml quand des besoins comme tel se font sentir avec un petit plugin on s'en sort très bien. Son avantage est surtout de faire un fichier (ou plusieurs pour plusieurs bases) facilement sauvegardable, administrable et portable.
Buster/NGINX/PHP7/PluXml5.8
Je dev sur un Raspberry à la configuration un peu Frankenstein-style, donc j’ai dû bricoler un peu avec les permissions, mais rien d’horrible. Et après m’être tapée la documentation de SQLite3, effectivement je pense que ça va être une solution adaptée (et “éducative et applicable”, ce qui est aussi une bonne chose et me fait choisir d’aller dans cette direction).
En ce qui concerne les éditeurs, j’ai trouvé SQLite Studio (pas encore testé - https://sqlitestudio.pl/index.rvt). Est-ce que c’est de l’ordre de ce que tu recommanderais pour la création en local, bazooka07 ?
Désolé d'avoir pris du temps à te répondre mais j'étais pas mal pris.
Si cela peut te rassurer j'ai un Raspberry aussi comme beaucoup d'autres.
Mais j'ai une préférence pour un Odroid C1 ou un OrangePi PC Plus qui tournent tous les deux sous Ubuntu.
Comme je développe sous Ubuntu sur PC, j'utilse les outils qui vont avec. Et donc Sqliteman
Il y a aussi Sqlitebrowser qui a l'air bien.
Je n'ai pas trouvé de paquet deb pour VisualStudio.
Pour créer les requêtes SQL un bon éditeur de code suffit. Ensuite on peut les appliquer en ligne de commande s'il y a un bug avec PHP.
Je suppose que tu as installé Raspbian sur ton RaspberryPi
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Entretemps je me suis habituée à travailler sur SQLite Studio donc pour l'instant je vais probablement rester dessus. (Je réalise que je n'étais pas claire - quand je dis dev sur Raspberry, je parle de mon serveur de test et il tourne sous Raspbian - en ce qui concerne le code, je travaille sous Windows, vu que c'est ce que j'ai sur mon ordinateur portable.)
Pour l'instant je suis surtout concentrée sur "réaliser des bases de données au design rationnel et efficace", l'implémentation dans PluXml vient après - mais les tests que j'ai déjà réalisés vite fait confirment que ça va clairement le faire, il s'agit surtout de bien réfléchir à tous les choix de design que je fais (notamment "quelles colonnes", ce genre de trucs).
En passant, un truc vraiment bien : Windows 10 a récemment ajouté une couche Linux à son système de fichiers (laquelle doit être activée pour être disponible). Donc en fait quand je suis en CLI sous Windows je suis quand même dans Linux. Ca a évidemment ses limites, mais au moins j'ai pas besoin d'apprendre la CLI de Windows et je peux utiliser apt-get et autres npm "depuis Linux".
Et du coup, en grande bricoleuse du dimanche je fabrique mes requêtes SQL via un script nodejs plutôt que de les taper à la main (il y a un datadump maintenu par des joueurs en JSON pour le jeu sur lequel je travaille, et on parle d'un petit millier de cases à remplir donc remplir la base SQLite à la main serait me garantir de faire des erreurs).
Bref. Vraiment merci de m'avoir pointée vers SQLite, c'est moins atroce que ce que je craignais à utiliser (euphémisme) et c'est vraiment une corde qui manquait à mon arc.
----
"Follow-up question" tant qu'à faire, parce que je me suis toujours posée la question - est-ce qu'il y a moyen d'ajouter un (ou plusieurs) chiffres à l'ID des articles et autres pages statiques dans PluXml (passer de 10k articles maximum à 100k articles maximum, par exemple) ? Pas que je m'attende à atteindre cette limite sur ce projet, loin de là, mais "en général" ça m'intéresse de savoir.
C'est une bonne initiative et c'est nettement que d'utiliser des trucs folkloriques comme wamp et cie.
Tu peux te connecter au raspi par ssh ou sftp pour lire les fichiers de log ou transférer des fichiers, voire les éditer depuis ton portable.
Je trouve les raspis assez chers . Pour moins cher il y a l'orange pi pc plus avec une mémoire EMMC de 8 Go, un port IR, un bouton pour arrêter proprement et wifi. Par contre il faut un délai d'un mois depuis la Chine.
Oui, avoir bien défini le schema de sa base de données est très important. Car revenir en arrière quand on a codé en PHP donne mal à la tête en général.
Follup-up Answer : Il n'y a de limite technique pour passer à 10000 ou 100000 articles. Il faut juste modifier les expressions régulières et le paramètre de longueur quand la fonction str_pad est utilisée. Pour l'instant, aucun utilisateur n'a réussi à atteindre la limite des 5000 articles malgré des années d'effort. Et PluXml supporte la charge.
Pour info, l'identifiant d'un article correspond aux 4 premiers chiffres du nom du fichier article
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Du coup ce que je fais c'est que je code en local et j'upload sur le Pi pour faire tourner tout ce qui est PHP et autres. C'est pas aussi fluide que de coder sous XAMPP et autres, mais c'est suffisant et je préfère de toute manière éviter de run PHP sur mon ordinateur de travail.
Merci pour les infos ! Je jette un oeil à l'Orange Pi.