IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Contribuez / Téléchargez Sources et Outils PHP Discussion :

Walousql


Sujet :

Contribuez / Téléchargez Sources et Outils PHP

  1. #1
    Membre à l'essai

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Avril 2020
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Avril 2020
    Messages : 4
    Points : 24
    Points
    24
    Par défaut 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 ?

  2. #2
    Expert éminent sénior
    Avatar de rawsrc
    Homme Profil pro
    Dev indep
    Inscrit en
    Mars 2004
    Messages
    6 142
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Dev indep

    Informations forums :
    Inscription : Mars 2004
    Messages : 6 142
    Points : 16 545
    Points
    16 545
    Billets dans le blog
    12
    Par défaut
    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 ?

  3. #3
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Lead dév - Architecte
    Inscrit en
    Août 2003
    Messages
    6 690
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Lead dév - Architecte
    Secteur : Industrie

    Informations forums :
    Inscription : Août 2003
    Messages : 6 690
    Points : 20 211
    Points
    20 211
    Par défaut
    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 ?
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  4. #4
    Membre à l'essai

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Avril 2020
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Avril 2020
    Messages : 4
    Points : 24
    Points
    24
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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

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

  5. #5
    Membre à l'essai

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Avril 2020
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Avril 2020
    Messages : 4
    Points : 24
    Points
    24
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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.

  6. #6
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Lead dév - Architecte
    Inscrit en
    Août 2003
    Messages
    6 690
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Lead dév - Architecte
    Secteur : Industrie

    Informations forums :
    Inscription : Août 2003
    Messages : 6 690
    Points : 20 211
    Points
    20 211
    Par défaut
    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

    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.

    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.

    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 ...)
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  7. #7
    Membre à l'essai

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Avril 2020
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Avril 2020
    Messages : 4
    Points : 24
    Points
    24
    Par défaut
    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

    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.

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo