DBX: tente se livrar da compilação de consultas MySQL

Há muito tempo, quando eu estava começando a aprender PHP e os meandros da compilação de consultas MySQL (2011), tive a ideia de escrever um wrapper para o MySQLi como o Doctrine para simplificar a sintaxe de acesso ao banco de dados. Já é 2019 e decidi compartilhar minha bicicleta no tema ORM.

E assim, esse é o DBX - o mecanismo de banco de dados MySQL para PHP baseado na biblioteca MySQLi, com base em consultas do tipo de descrição estrutural das tabelas e campos do banco de dados na forma de uma matriz regular com a função de cache estático de consulta e atualização automática do hash estático.

Ao contrário do amor geral da DOP, foi escolhida a leve funcionalidade do MySQLi, que é mais suave e fácil de programar e se encaixa de forma mais concisa na API DBX proposta. Eu nem sequer usei o compositor, porque não tenho nenhum projeto em que uso dependências de terceiros além das auto-escritas.

Na verdade, considere um exemplo de declaração da estrutura de um banco de dados de teste simples e de suas tabelas. Primeiro, conectaremos a própria biblioteca à classe e enviaremos os dados de autorização ao host do banco de dados:

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

Agora imagine que precisamos descrever e criar uma tabela no banco de dados usando a sintaxe de uma matriz PHP regular:

 <?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') ] ]; ?> 

A sintaxe é simples aqui. Não usei digitação forte e apenas escolhi os valores TEXT, NUMBER e TYMESTAMP. Obviamente, para uma estrutura mais "direcionada" da tabela, é usado o ID do campo-chave com incremento automático (não vi casos em projetos reais ao definir o incremento automático e a chave interfere no design das consultas e nos relacionamentos da tabela). Para indicar se o campo pode estar vazio, preencha => true é especificado.

Os tipos de consulta do DataBaseX são muito simples e contêm métodos básicos como selecionar, inserir, excluir, atualizar, excluir, truncar e assim por diante.

Por exemplo, uma consulta para criar uma tabela:

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

Ou uma consulta para adicionar dados e uma estrutura de coluna pode ser assim:

 // 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); 

A estrutura da matriz permite que um dia descreva o banco de dados e, posteriormente, apenas manipule os campos de valor para modificar os dados usados ​​para formar consultas.

Aqui está um exemplo de instrução de atualização, que eliminarei no exemplo a seguir:

 // 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); 

Pareceu-me que o uso dos campos criterion_field e criterion_value complica o sistema, por isso criei uma consulta que adiciona automaticamente dados ao banco de dados se ele ainda não foi criado ou atualiza os dados existentes. Eu chamei essa consulta de INJECT QUERY e é chamada pelo prefixo "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); 

Isso funciona em um nível baixo como este:

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

Todas as outras consultas são as mais simples e não faz sentido descrevê-las (veja exemplos no arquivo de teste index.php), mas não posso deixar de mostrar como a consulta SELECT funciona:

 <?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 />'; ?> 

Aqui, usando o prefixo "s", você pode agrupar os parâmetros de consulta s | field_id ( ordem ) | asc ( direção ) | 100 ( limite ) | 0 ( deslocamento ) .

Entre outras coisas, o DBX possui um recurso tão distinto como um cache de arquivo interno baseado nas estáticas JSON. Cada solicitação de alteração (INSERT, UPDATE, DELETE, TRUNCATE) faz com que o hash seja calculado na tabela de hash do cache e atualiza automaticamente o cache estático, o que permite que você não pense na carga nas consultas SELECT.

No futuro, planejo desenvolver o mecanismo DBX e expandir os recursos do designer de consultas SQL usando o sistema de configuração UNION e JOIN, além de adicionar novo suporte ao banco de dados do MySQL 8 com base no tipo de estrutura JSON.

Agora, o DBX é usado no meu sistema de gerenciamento de conteúdo RevolveR e mostra boas características (todo o site, desde que haja um cache atualizado, é inicializado com uma consulta ao banco de dados e consome cerca de 0,7 Mb de RAM do interpretador). Também é muito conveniente ver toda a estrutura do banco de dados em um arquivo separado, o que às vezes acelera a criação e o design de novos módulos.

Repositório do projeto: DBX v1.1.1 no GitHub .