(Pseudo) base de données ?

Kalista · février 2018

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 ?

Francis · février 2018

Spxdatas est un plugin génial, qui peut effectivement remplacer une base de données, pour des besoins comme les tiens.

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.

Kalista · février 2018

"Ah, la documentation était donc dans le dossier lang..."

D'accord, merci. Je vais lire ça tranquillement, ça a effectivement l'air de pouvoir faire l'affaire.

bazooka07 · février 2018

Si tu as quelques notions de langage SQL, à ta place direct je pars sur une base SQLITE3.
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.

Kalista · février 2018

Also fair... je vais au moins aller jeter un oeil, ça fait bien huit ans que je n'ai pas touché de (vraie) base de données mais il serait peut-être temps de réapprendre et ma raison principale de les éviter (difficulté de migration, dépendance au serveur) semble annulée par le fait que SQLITE3 stocke tout dans un seul fichier.

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.)

bazooka07 · février 2018

Pour info, Firefox ( le panda roux ) utilise SQLite3 pour stocker une partie de ses données.

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

Pierre · février 2018

C'est presque dommage car toute l'explication donnée au début s'utiliserait très bien avec la structure de base de PluXml. Des catégories bien nommées avec leur jeu d'articles construits avec des gabarits adaptés, tout semble en place pour une vie bien plus simple. Et c'était aussi bien parti avec SPXDATAS, surtout si on regarde du côté des shortcodes.

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.

bazooka07 · février 2018

Utiliser SQLite3 ce n'est pas installer et administrer un serveur MySQL !

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.

Pierre · février 2018

Ah, je suis d'accord, je suis un peu un fan discret de SQLite3 mais je suis tout de même d'avis que l'exemple mentionné ne l'exige pas à première vue. Ceci dit, c'est un excellent produit qui fait la barbe aux grand joueurs du marché.

Yannic · février 2018

Même si dans les fait c'est tout à fait possible en un ou quelques fichier xml et en suivant le fonctionnement de pluxml.

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.

Kalista · février 2018

Merci à tous pour vos retours, c'est super informatif.

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 ?

bazooka07 · mars 2018

Bonjour Kalista,

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

Kalista · mars 2018

Ah, pas de problème !

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.

bazooka07 · mars 2018

Je me suis bien demandé si tu utilisais l'interface graphique de Raspbian

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

Kalista · mars 2018

Il y a eu une époque où je codais sous Raspbian pour de petits projets mais j'ai arrêté, c'est juste trop contraignant par rapport à juste utiliser un ordinateur portable je trouve. (Encore qu'il y a moyen avec les écrans à distance, en fait.)

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.

(Pseudo) base de données ?

Réponses