Walousql

Version imprimable

05/04/2020, 17h39
Kaixo

Walousql

Bonjour,

Je vous propose un nouvel élément à utiliser : Walousql

Walousql est un SGBD (système de gestion de base de données) en PHP qui ne nécessite aucun autre moteur ou logiciel. Les données sont directement stockées au même endroit que vos scripts.

Qu'en pensez-vous ?
05/04/2020, 19h50
rawsrc

salut,

l'effort est louable mais je reste quand même dubitatif pour plusieurs raisons.
Je n'ai pas vu la gestion des jointures,
vu que tu parles de SGBDR, je m'attendais à trouver au moins la norme SQL implémentée un poil, tu remplaces NOT NULL : !null , euh ça pique...
Enfin l'autre argument de taille c'est que la gestion sous forme de fichiers .php va faire qu'à chaque fois que tu va accéder à une table, t'es obligé de tout charger en mémoire... Et la mémoire en PHP n'est pas infinie généralement.
Après tu as la possibilité de stocker à peu près ce que tu veux sous forme de fichiers en PHP avec le mécanisme de sérialisation.

Enfin, si tu cherches un moteur SGBDR local basé sur les fichiers plats tu as quand même le génialissime SQLite qui fait le taf et même le café.

Tu l'as utilisé en production ton système ?
06/04/2020, 10h33
grunk

D'un point de vue sécurité y'a intérêt d'être sacrément carré dans ce qu'on donne à ton système.
Y'a t'il des gardes fou qui éviterais l'injection de code ?

Bonjour Rawsrc,

Déjà, merci de t'être intéressé à ma source. Je me permets de préciser mes motivations pour la création d'une telle classe :

J'ai travaillé sur des transferts de sites Internet de serveur à serveur. Je me suis alors rendu compte qu'il y avait beaucoup de WordPress pour juste une douzaine de posts. Ce qui revient à utiliser la bombe H pour tuer un coléoptère. Et de manière générale, j'ai relevé un gros défaut des développeurs : ils se précipitent sur l'utilisation d'une base SQL pour stocker une poignée de données.
D'un autre côté, les hébergeurs ouvrent beaucoup plus facilement des accès aux scripts qu'aux bases de données. J'ai même vu un gros site se connecter à la base en root !
Enfin, j'ai récupéré des sites en PHP5 et pour les adapter à PHP7, ce qui veut dire changer tous les mysql_xxxxx en mysqli_xxxxx...

Je suis actuellement sur un projet créations de plusieurs petits sites pour des petits clients sur un serveur que je gère. Un client voulait avoir accès aux sources, quitte à changer d’hébergement. J'ai naturellement pensé à SQLite. Mais chez certains hébergeurs, on peut être amener à modifier le php.ini. Et l'édition des tables nécessitent un logiciel.
C'est pour ça que j'ai eu l'idée de créer une petite classe prête à l'emploi (sans rien modifier sur le serveur), compatible PHP5 et PHP7, qui permet de jouer avec des petites bases de données.

Walousql est SGDB et non un SGBDR. Il est plus dans l'esprit d'un NoSQL (d'où le nom : "walou" qui signifie "rien du tout" en argot). Donc il n'y a pas de notion native de jointure. Je t'avoue que ça m'a aussi gêné. Mais pour palier ce manque, il y a deux remèdes :
1/ Walousql peut stocker nativement des structures plus complexes qu'en SQL, comme des tableaux de tableaux.
2/ Par mon expérience, j'ai remarqué que les jointures appellent rarement plus de deux ou trois tables. L'équivalent en Walousql n'est pas non plus trop laid :
Code:

1 2 3 4 5 6 7 8 $walousql = new walousql(); $walousql->setTable('table1'); $table1 = $walousql->selectAll(); $walousql->setTable('table2'); foreach ($table1 as $key1 => $row1){ $rows2 = $walousql->selectByKey($row1['un_id_dans_la_table1']); }
Pour la fonction search, j'ai voulu mettre des "vrais/faux morceaux" de SQL. J'aurais pu mettre "NOT NULL" à la place de "!null", comme il existe "and" à la place de "&&". Ta remarque est très judicieuse. Je te promets d'en tenir compte à la prochaine mise à jour !

Pour la gestion de la mémoire, je suis tout à fait d'accord avec toi. Plus que de charger toute la table en mémoire en lecture, c'est de réécrire toute la table qui me semble très gourmand. J'ai donc pensé à décomposer les tables en plusieurs fichiers PHP. Une telle gestion aurait eu deux inconvénients :
1/ Il aurait rendu la classe beaucoup plus compliquée et se serait éloigné de l'esprit "less is more" de départ
2/ L'édition des tables à la volée (pour ne pas dire à l'arrache) avec un éditeur de code aurait été moins aisée

Je peux me tromper, mais le var_export que j'utilise est en quelques sorte un mécanisme de sérialisation. Ou du moins, un cousin très proche. J'avais pensé stocker les données en JSON. Mais l'avantage du var_export est de pouvoir utiliser un simple include pour la lecture, sans aucune "dé-sérialisation". Je pense d'ailleurs ajouter pour une prochaine version une option permettant de stocker les données en JSON pour les rendre compatibles avec d'autres langages (comme mon chouchou Python).

Dans les conditions du réel, j'ai récupéré le site d'un restaurant existant depuis presque deux ans (avec suggestions du jour, réservations, avis, etc.) en MySQL que j'ai migré en Walousql. Le transfert de données s'est fait instantanément et le site ne souffre d'aucun ralentissement.
En revanche, j'ai essayé d'utiliser Walousql pour un autre projet en tentant d'exploiter toutes les transactions immobilières sur ces 5 dernières années (plus de 10 millions d'enregistrements). Je me suis vite rabattu sur MariaDB :lol:

En tout cas, je suis très heureux de voir que ma petite contribution suscite un peu de curiosité !

06/04/2020, 13h11
Kaixo
Bonjour Grunk,

Pour avoir été victime il y a quelques temps de très lourdes injections SQL, j'ai évidement pensé à la sécurité...

Si le serveur est bien configuré, c'est l'utilisateur "apache" qui exécute les scripts PHP. Donc il ne peut pas trop faire ce qu'il veut dans des dossiers sensibles.

Les noms de tables doivent répondre à une expression régulière assez stricte qui interdit les "/" et les "\".
Ainsi, il n'est pas possible de faire des :
Code:

1 2 3 $walousql->setTable('/etc/httpd') $walousql->setTable('../../../')
C'est dommage, j'aurais bien aimé utiliser des tables dans des dossiers pour un meilleur classement, mais j'ai préféré privilégier la sécurité.
De plus, Walousql ne lit et n'écrit que dans des documents qui se terminent par ".table.php".

Enfin, je fais confiance à var_export pour sécuriser le contenu des tables. var_export gère tout seul les simples et doubles quotes, retours à la ligne, et autres caractères exotiques.
06/04/2020, 13h57
grunk

Pour moi c'est justement l'utilisation de var_export qui est le risque le plus important.

A mon avis en cherchant un petit peut il est relativement simple d'injecter du code PHP qui va s'executer, par exemple, en le plaçant au millieu du texte d'un article.
C'est le problème de stocker du code et non des chaines (comme dans une bdd classique). Si je veux enregistrer un article (par exemple) il est extrêmement difficile dans un texte de détecter que ce que je vais enregistrer est du code malicieux et non un simple texte.
Mais dans un environnement très contrôlé pourquoi pas :)

Citation:

Je me suis alors rendu compte qu'il y avait beaucoup de WordPress pour juste une douzaine de posts. Ce qui revient à utiliser la bombe H pour tuer un coléoptère.

C'est surtout une question de rentabilité. Un wordpress ca se met en place en 5 min chrono. 2 plugins et un thème plus tard le client à son site prêt. C'est pas optimisé , c'est pas pro mais c'est rentable , c'est pour ca que quasi la totalité des agences web fonctionne comme ca.

Citation:

j'ai relevé un gros défaut des développeurs : ils se précipitent sur l'utilisation d'une base SQL pour stocker une poignée de données.

Ca c'est la maladie des dév qui ne font que du web et ne font pas d'autre langage plus orienté client lourd , où généralement, la bdd est le dernier choix. :)

Citation:

Enfin, j'ai récupéré des sites en PHP5 et pour les adapter à PHP7, ce qui veut dire changer tous les mysql_xxxxx en mysqli_xxxxx...

Ca c'est un problème de dev pas compétent/ pas à jour. Ça fait 15 ans que PDO existe , ca fait 15 ans que ca devrait être utilisé par tout le monde et ce genre de problème n'existerait pas.

Je pense que ta lib est un exercice intéressant, mais j'y vois trop de risque.

Toutes les solutions à base de fichiers plats fonctionnent en général sur des fichiers text (dokuwiki, picocms, grav cms ,etc ...)
06/04/2020, 15h48
Kaixo

Grunk,

Je surestime peut-être var_export, mais cette fonction ne me paraît pas plus exposée aux injections que les BindParam de PDO.
J'ai essayé en mettant un /* en plein milieu d'un texte par exemple : aucun problème à l'écriture, ni à la lecture.

Sincèrement, je serais le premier intéressé si tu trouves une faille qui pourrait faire "vaciller" var_export :ave:

Bien sûr, je ne parle pas de bidouille avec le HTML en mettant l'ouverture d'une balise qui ne se ferme pas (ou de <!--)... Comme avec SQL, c'est au développeur de gérer ça.