DBX: tenter de se débarrasser de la compilation des requêtes MySQL

Il y a longtemps, alors que je commençais à peine à apprendre PHP et les subtilités de la compilation de requêtes MySQL (2011), j'ai eu l'idée d'écrire un wrapper pour MySQLi comme Doctrine pour simplifier la syntaxe d'accès à la base de données. C'est déjà 2019 déjà et j'ai décidé de partager mon vélo sur le thème ORM.

Et donc, c'est DBX - le moteur de base de données MySQL pour PHP basé sur la bibliothèque MySQLi basé sur les requêtes de la description structurelle des tables et des champs de la base de données sous la forme d'un tableau régulier avec la fonction de mise en cache des requêtes statiques et la mise à jour automatique du hachage statique.

Contrairement à l'amour général du PDO, il a été choisi la fonctionnalité légère MySQLi, qui est plus douce et plus facile à programmer et s'intègre de manière plus concise dans l'API DBX proposée. Je n'ai même pas utilisé Composer, car je n'ai pas un seul projet où j'utilise des dépendances tierces autres que l'auto-écriture.

En fait, considérons un exemple de déclaration de la structure d'une base de données de test simple et de ses tables. Tout d'abord, nous allons connecter la bibliothèque elle-même à la classe et envoyer les données d'autorisation à l'hôte de la base de données:

require_once './DBX.php'; $dbx_data = ['localhost', 'root', 'root', 'dbx_test', '8889']; 

Imaginez maintenant que nous devons décrire et créer une table dans la base de données en utilisant la syntaxe d'un tableau PHP standard:

 <?php /** * CREATE TABLE EXAMPLE */ $table_1 = 'example'; // table name $query_1 = 'c'; // create table sql $fields_1 = [ 'field_id' => [ 'type' => 'num', // int 'auto' => true, // auto increment 'length' => 255, 'fill' => true // not null ], 'field_text' => [ 'type' => 'text', // varchar 'length' => 255, 'fill' => true ], 'field_date' => [ 'type' => 'time', // TIMESTAMP 'value' => date('Ym-d') ] ]; ?> 

La syntaxe est simple ici. Je n'ai pas utilisé de frappe forte et j'ai simplement choisi les valeurs TEXT, NUMBER et TYMESTAMP. Bien sûr, pour une structure plus «directrice» de la table, l'ID de champ clé avec incrémentation automatique est utilisé (je n'ai pas vu de cas dans des projets réels lorsque la définition de l'incrémentation automatique et de la clé interfère avec la conception des requêtes et des relations de table). Pour indiquer si le champ peut être vide, fill => true est spécifié.

Les types de requête DataBaseX sont très simples et contiennent des méthodes de base telles que sélectionner, insérer, supprimer, mettre à jour, supprimer, tronquer, etc.

Par exemple, une requête pour créer une table:

 // perform queries $dbx::query("c", $table_1, $fields_1); 

Ou une requête pour ajouter des données et une structure de colonnes pourrait ressembler à ceci:

 // fields values for table_1 example $fields_2 = [ 'field_id' => [ 'value' => 456 ], 'field_text' => [ 'value' => 'I have to add into my table' ], 'field_date' => [ 'value' => date('Ym-d') ] ]; // perform queries $dbx::query('i', $table_1, $fields_2); 

La structure du tableau permet un jour de décrire la base de données et ensuite de manipuler uniquement les champs de valeur pour modifier les données qui sont utilisées pour former des requêtes.

Voici un exemple de déclaration de mise à jour, que j'éliminerai dans l'exemple suivant:

 // fields values for table_1 example $fields_3 = [ 'field_id' => [ 'value' => 456 ], 'field_text' => [ 'new_value' => 'I was updated', 'criterion_field' => 'field_id', 'criterion_value' => 456 ], 'field_date' => [ 'value' => date('Ym-d') ] ]; // perform queries $dbx::query('u', $table_1, $fields_3); 

Il m'a semblé que l'utilisation des champs crit_field et crit_value compliquait le système, j'ai donc créé une requête qui ajoute automatiquement des données à la base de données si elle n'a pas encore été créée ou met à jour les données existantes. J'ai appelé cette requête INJECT QUERY et elle est appelée par le préfixe "in":

 // fields values for table_1 example $fields_2 = [ 'field_id' => [ 'value' => 0 ], 'field_text' => [ 'value' => 'Yo if field_id = 0 it\'s an insert or if id exists it\'s an update' ], 'field_date' => [ 'value' => date('Ym-d') ] ]; // perform queries $dbx::query('in', $table_1, $fields_2); 

Cela fonctionne à un niveau bas comme celui-ci:

 INSERT INTO `revolver__comments` (`field_id`, `field_content`) VALUES ('5', 'TEST UPDATE') ON DUPLICATE KEY UPDATE `field_id`='5', `field_content`='TEST UPDATE'; 

Toutes les autres requêtes sont les plus simples et cela n'a aucun sens de les décrire (voir les exemples dans le fichier de test index.php), mais je ne peux pas m'empêcher de montrer comment fonctionne la requête SELECT:

 <?php // perform queries $dbx::query('s|field_id|asc|100|0', $table_1, $fields_1); ?> <?php // print structure print '<h2>DBX STRUCTURE</h2>'; print '<pre><code>'; print_r( $fields_1 ); print '</code></pre>'; // print result print '<h2>DBX QUERY RESULT</h2>'; print '<pre><code>'; print_r( $dbx::$result ); print '</code><pre><hr />'; ?> 

Ici, en utilisant le préfixe "s", vous pouvez regrouper les paramètres de requête s | field_id ( ordre ) | asc ( direction ) | 100 ( limite ) | 0 ( offset ) .

Entre autres choses, DBX possède une caractéristique aussi distincte qu'un cache de fichiers intégré basé sur la statique JSON. Chaque demande de changement (INSERT, UPDATE, DELETE, TRUNCATE) provoque un calcul de hachage dans la table de hachage du cache et met automatiquement à jour le cache statique, ce qui vous permet de ne pas penser à la charge des requêtes SELECT.

À l'avenir, je prévois de développer le moteur DBX et d'étendre les capacités du concepteur de requêtes SQL à l'aide du système de configuration UNION et JOIN, ainsi que d'ajouter un nouveau support de base de données à partir de MySQL 8 basé sur le type de structure JSON.

Maintenant, DBX est utilisé dans mon système de gestion de contenu RevolveR et présente de bonnes caractéristiques (l'ensemble du site, à condition qu'il y ait un cache mis à jour, est initialisé avec une requête dans la base de données et consomme environ 0,7 Mo de RAM d'interprète). Il est également très pratique pour moi de voir toute la structure de la base de données dans un fichier distinct, ce qui accélère parfois la création et la conception de nouveaux modules.

Référentiel de projet: DBX v1.1.1 sur GitHub .