Bonjour à tous. Un petit projet d'Abstraction SQL m'amène à poster le présent sondage sur ce que vous utilisez comme fonctionnalités quand vous faite intéragir PHP avec vos bases de données (pas forcément limité à MySQL). Il y a les requêtes simples, exécutées et préparées qui sont des classiques, et pour les jeux de résultats il y a le fetchage en array associatif qui est classique, mais que dire du reste ? Quelles fonctionnalités voudriez-vous avoir sous la main si une telle abstraction venait à voir le jour ? Quelles fonctionnalités sont en définitives inutiles à intégrer ? Plus il y aura d'avis et de commentaires sur la question, meilleure sera l'API résultante.
Pour les curieux, je met les liens vers la doc de différentes API, il y a parfois des fonctionnalités qu'on ignore.
Couches d'abstraction : PDO (accède à CUBRID, SQL*Server, Firebird, IBM, Informix, MySQL, Sybase, Oracle, ODBC/DB2, PostgreSQL, SQLite, 4D ODBC unifiée (accède à Adabas D, IBM DB2, iODBC, Solid, Sybase SQL Anywhere DBA (Accède à Oracle Berkeley DB) dbx (PECL, accède à MySQL, ODBC, Oracle (oci8), SQL*Server, PostgreSQL, FrontBase, Sybase-CT, SQLite)
Typages de paramètres moins classiques : DATE, DATETIME, TIME
Détection des typages par défaut en fonction des paramètres passés
Méthodes ORM telles que select(), update()... (via classe de type Adapter probablement)
Mécanisme de "fichier(s) de config" servant notemment à l'écriture d'identifiants multiples en fonction du lieu d'exécution (peut-être pas uniquement ce genre de config)
Fonctionnalités abandonnées
Méthodes raccourcis (telles que mysql_create_db())
A vos claviers, et merci d'avance.
- Edité par Darth Killer 5 juillet 2014 à 15:31:48
Un projet intéressant que j'ai déjà pu voir dans certaines entreprises. Ce que j'ai pu apprécier en utilisant ce genre Class sont les requêtes d'écritures qui généraient elles mêmes les requêtes et les différentes fonctions pour changer les limites du SGDB.
Ex :
Le Insert / Update / Replace / InsertMultiple qui formattent la requête en prenant que 2 ou 3 requêtes du style :
/*
* 1 param : nom de la table
* 2 param : tableau contenant le nom de champs avec la donnée associé
*/
$this->db->Insert("nom_table", array("name" => "toto"));
/*
* 1 param : nom de la table
* 2 param : tableau contenant le nom de champs avec la donnée associé
*/
$this->db->Replace("nom_table", array("name" => "toto"));
/*
* 1 param : nom de la table
* 2 param : tableau contenant le nom de champs avec la donnée associé
*/
$this->db->InsertMultiple("nom_table", array(array("name" => "toto"), array("name" => "titi")));
/*
* 1 param : nom de la table
* 2 param : tableau contenant le nom de champs avec la donnée associé
* 3 param : le where
*/
$this->db->Update("nom_table", array("name" => "toto"), " id = 2");
Cela permet aux personnes pas forcément à l'aise avec la syntaxe SQL de pouvoir manipuler la BDD dans tous les cas.
Et concernant la modification des limites, je pense à la limite de caractère d'un GROUP_CONCAT par exemple.
C'est tout ce qui me vient à l'esprit pour le moment.
Ah si, une requête qui permet de protéger tes champs, une sorte de escape, qui fait les bonnes vérifications selon le type, ...
Non bah c'est ce qu'on appelle un fail en toute beauté, dans mon esprit j'ai totalement confondu ORM et abstraction SQL, du coup tout ce que je t'ai dis concerné un ORM
Au temps pour moi.
Pour le GROUP_CONCAT, il m'est déjà arrivé d'atteindre la limite de data autorisé, du coup j'ai du l'augmenté et il faut appeler une certaine commande pour cela mais c'est de l'ordre de l'ORM, du coup mon post t'avance pas à grand chose .
J'avoue en être resté au simple CRUD avec requêtes préparées, je n'ai encore que très rarement eu utilisé les transactions, et ça s'arrête un peu là pour ce qui est du SQL pur
Par contre, à une époque, j'avais fait une petite API qui détectait le type des paramètres passés à une requête préparée. On pouvait inférer sur le type des paramètres, mais par défaut un INT était bien considéré comme un nombre, les chaînes de caractères étaient échappées et les dates (DateTime) étaient formatées, donc je trouverais sympa de trouver ce genre de fonctionnalité
J'aimerais volontiers savoir ce que tu fais comme distinction entre un ORM et une couche d'abstraction de base de données (DBAL), s'il te plaît, je t'avoue que moi-même j'ai de la peine à exprimer la différence que je fais.
Pour moi (mais peut-être suis-je à l'extrême), une DBAL permet de construire des requêtes sans se soucier du SGBD utilisé, par exemple avec des fonctions/méthodes diverses (on ne s'abstrait que de la partie SQL, la logique de construction des requêtes reste au développeur : select(array('maColonne', 'monAutreColonne'), 'maTable')->join('monAutreTable', array('source' => 'colonneReferencee'))->where(…)). Cela devient un ORM quand on manipule directement des classes et s'arrange pour accéder aux propriétés, déterminant ainsi la table à utiliser, les colonnes, etc., pour ensuite s'appuyer sur la DBAL qui construira les requêtes (on fait aussi abstraction de la logique de construction des requêtes). Et puis, comme l'abréviation le mentionne, on a la notion de mapping qui intervient, donc une description d'une manière ou d'une autre des objets utilisés et de leur "correspondance" en base de données.
Je prends note de l'appellation DBAL, qui m'a l'air plus sérieuse.
En gros la différence majeure entre DBAL et ORM est qu'avec une DBAL, tu écris quand même tes requêtes, de manière plus ou moins assistée, mais tu écris du SQL quand même. Avec un ORM, ce n'est pas le cas, tu passes par les méthodes de la classe qui rédigent en interne la requête. En fait, les ORM plus poussés vont plus loin en fabriquant automatiquement les tables et leur structure d'après un fichier de config que tu fournis, et en créant aussi les classes métier qui vont avec.
Une DBAL permet d'intéragir avec n'importe quel type de SGBD avec la même syntaxe objet. Dans les faits bien souvent, tu as des classes spécialisées pour chaque SGBD, qui obéïssent à des interfaces communes, et tu as une classe qui fabrique les objet de ces classes sans te dire de quel type il s'agit. Et tu t'en fous : tu connais l'interface commune et le comportement "publique" commun. Par contre, il faut quand même les lui donner, les requêtes, elles ne les rédige pas toute seule. Il peut y avoir quelques raccourcis sympa, par exemple la DBAL commue de C#.NET (appelée ADO.NET) permet de donner à un objet DbCommand (qui symbolise la requête) un type "procédure stockée", auquel cas la string de "requête" que tu lui donne est juste le nom de la procédure, et en interne l'objet DbCommand transforme ça en la requête SQL réellement lancée. Par exemple, une DbCommand pour MySQL (je pense que la classe est effectivement MysqlDbCommand) dont la "requête" est simplement "ajouterPersonnage" avec 2 paramètres "Sangoku" et 18, la requête rédigée en interne serait quelque chose de ce genre :
CALL ajouterPersonnage('Sangoku', 18);
Mais il a fallu quand même indiquer le nom de la procédure (en tant que texte de requête, soit), injecter les paramètres, et exécuter le tout. Pas de méthode select(), join(), et compagnie.
Pour faire le rapprochement, PDO est une très bonne DBAL. On pourrait d'ailleurs se demander pourquoi je veux en faire une, du coup. Sa liste de DB compatibles est limitée, et surtout ce sont des extensions. Avec cette nouvelle DBAL, non seulement les possibilités en SGBD compatibles seraient accrues, mais si une extension n'est pas présente, cette DBAL serait alors capable de rebondir sur une autre extension en interne. Sauf bien sûr s'il n'y en a aucune. Résultat : si pour MySQL tu as PDO_mysql en local et que tu ne l'as pas sur ton serveur, tu t'en fous : la DBAL s'adapte de manière transparente.
J'avais surtout compris qu'une DBAL permettrait de s'affranchir des différences entre les nombreux SQLs, mais du coup, c'est plus du ressort d'un ORM, alors ?
Les 2, c'est juste une différence bas-niveau/haut niveau. Un ORM peut envoyer les requêtes concrètes qu'il rédige en interne à une DBAL. De la sorte, l'ORM ne sait pas forcément à quel type de SGBD il est connecté, et il n'a pas besoin de le savoir.
L'intérêt d'une DBAL c'est d'utiliser de manière identique différents SGBD alors que leurs API natives sont différente. Une DBAL est un adaptateur, en gros.
Donc une DBAL ne permet pas de s'abstraire d'un SQL, mais d'une API pour lancer une commande SQL, c'est bien ça ?
<small>Si j'apprends quelque chose, autant l'apprendre juste Désolé pour la longueur de la discussion qui en découle</small>
Elle ne sert pas à s'abstraire du SQL, mais de s'abstraire des spécificités de chaque SGBD (de part les méthodes de leurs API, et de part leurs écarts au SQL, notamment dans le domaine des procédures stockées et compagnie).
Par exemple, l'appel à une procédure en MySQL passe par le mot-clé CALL. En SQL*Server, c'est le mot-clé EXEC. Une DBAL te permet de t'abstraire de ça en proposant une interface pour exécuter les procédure, interface implémentée par des classes concrète qui ELLES sont spécifiques aux SGBD. Toi, en tant qu'utilisateur, tu ne vois que l'interface générale et elle te suffit.
// Je ne gère pas la problématique des paramètres sur cet exemple
interface iDBAL {
/* .. */
public function exec_procedure($name);
}
class DBAL_MySQL implements iDBAL {
/* .. */
public function exec_procedure($name) {
$this->exec("CALL $name;");
}
}
class DBAL_SQLServ implements iDBAL {
/* .. */
public function exec_procedure($name) {
$this->exec("EXEC $name;");
}
}
class DBProvider {
getMySQLConnect() { /* répond un objet DBAL_MySQL */ }
getSQLServConnect() { /* répond un objet DBAL_SQLServ */ }
}
$provider = new DBProvider();
$db = $provider->getMySQLConnect();
$db->exec_procedure('maproc');
$db = $provider->getSQLServConnect();
$db->exec_procedure('maproc');
Comme tu l'as déjà énoncé, PDO est déjà très complet à ce niveau là. S'il s'exprime sous la forme d'extension, c'est parce que le code est compilé donc plus performant.
PDO couvre la plupart des SGBD grand public donc c'est s’embêter pour très peu de choses au final. Et je m'avance peut être mais tu dois avoir possibilité d'écrire ta propre extension pour ton driver incompatible avec PDO (Par contre c'est du langage C donc il faut un peu plus s'accrocher ).
Moi, un des seuls reproches que j'ai pu faire avec PDO est que la récupération des informations lors d'une requête SELECT est "case sensitive" selon le SGBD. Le plus simple pour comprendre est que j'avais un projet en MySQL que j'ai voulu passer en Oracle, le code suivant ne marchait plus :
<?php
$statement = $pdo->prepare('SELECT toto FROM ... WHERE id=:id');
$statement->execute(array(':id', 1));
foreach ($sth->fetchAll(PDO::FETCH_ASSOC) as $record){
// En Mysql pour accéder à la colonne :
$record['toto'];
// Avec Oracle
$record['TOTO'];
}
// à l'époque, la configuration PDO::ATTR_CASE n'existait pas mais ce problème est résolu
?>
- Edité par devil may cry 5 juillet 2014 à 13:57:48
Le fait qu'il s'agisse d'une extension est à la fois une force et une faiblesse : qui te dit que ton hébergeur l'a installée ? Devoir refaire toute ta DAL avec une autre extension juste parce que l'hébergeur n'a pas celle que tu utilisais ou comptais utiliser est un sacré effort. Si ta couche d'abstraction n'est pas une extension et ne dépend pas une extension particulière, c'est un problème en moins à se poser.
Et pour ce qui est des performances, c'est bon, loin derrière nous l'époque du 286. A moins de faire un code de cochon, ça restera assez rapide.
Le fait qu'il s'agisse d'une extension est à la fois une force et une faiblesse : qui te dit que ton hébergeur l'a installée ? Devoir refaire toute ta DAL avec une autre extension juste parce que l'hébergeur n'a pas celle que tu utilisais ou comptais utiliser est un sacré effort. Si ta couche d'abstraction n'est pas une extension et ne dépend pas une extension particulière, c'est un problème en moins à se poser.
Et pour ce qui est des performances, c'est bon, loin derrière nous l'époque du 286. A moins de faire un code de cochon, ça restera assez rapide.
Ton exemple n'est pas pertinent, si tu es sur un SGBD il te faut au moins l'extension PHP pour requêter sur celui-ci. Tu crois que tu peux écrire un driver de SGBD avec du PHP de la sorte ? (sans passer par les mysql_query, mssql_query, ... qui nécessitent leur extension spécifique) si oui, je suis curieux de la solution.
Pour les performances, c'est un autre débat mais je pense que si le PHP est suffisamment réactif de nos jours, c'est aussi parce que les tâches les plus lourdes en traitement sont déportées dans ces modules. Après je dirais qu'un autre avantage des modules est qu'il charge une instance unique fonctionnalités. Une sorte de Singleton en PHP mais qui se conserve tant que le serveur est en fonction (impossible de faire ce mécanisme avec du code PHP Serveur).
En fait on s'en fout que l'hébergeur aie ou pas activé l'extension dont tu aies besoin, parce que si tu veux bien faire les choses, t'es un peu sensé, dès le départ, avoir un environnement de dev et de prod identique.
Par ailleurs, même si tu fais tout à l'envers, que t'as déjà tout développé avec un sgbdr spécifique et que tu n'as pas encore d'hébergeur, il faut être sacrément ahuri pour ne pas penser à ça quand tu choisis un hérbergeur.
Et vu la facilité/cout de changer d'hébergeur, même si on est ahuri, on s'en fiche vraiment en fait.
Comme l'a dit devil, tu seras de toute façon toujours tributaire de l'extension pdo/spécifique du sgbdr utilisé, donc ton api sera à peine plus résiliente que pdo vu qu'au mieux t'auras juste un fallback sur l'extension spécifique.
Après ça ne doit pas t'empêcher de mener ton projet à termes, nombres de projets ont été et seront menés pour le simple plaisir.
Prends par exemple MySQL. Il existe 3 extensions différentes pour faire intéragir PHP avec. Et de mon expérience avec Free (hébergement gratuit), si une extension est présente sur l'hébergeur aujourd'hui ne veut pas qu'elle le sera demain. Ils n'ont jamais disposé du pilote MySQL pour PDO mais ils avaient l'extension MySQLi pendant pas mal de temps. Ils l'ont enlevée pour dieu sait quelle raison. Si ton site en était dépendant, tétais obligé de tout réécrire...
Avec un système ne dépendant pas d'une extension spécifique pour agir avec un type de base de données, Si une extension est absente, il essayera tout simplement la suivante jusqu'à être à court d'options.
Un petit schéma simpliste (et fait à l'arrache) de ce que ça pourrait donnée, du moins dans l'idée. On appelle la classe de départ juste pour qu'elle nous donne une fabrique en fonction du SGBD qu'on veut utiliser. Du coup, on ne sait pas quelle type d'objet exacte elle nous donne et on s'en fout : on sait juste que ça hérite de DynSQLFactory et donc qu'on a un certain nombre de méthode à disposition : réglages d'options, configurations, etc... et obtention de l'objet de connection central. Là encore on ne saura pas quelle classe exacte c'est et on s'en fout, ça hérite de DynSQLConnection.
En MySQL, on ne saura donc pas si on passe par PDO, MySQLi ou MySQL, tout ça se fera de manière transparente. C'est le but central.
// Exemple d'utilisation pour MySQL
// Détails pas fixés loin de là, c'est juste pour l'illustration
$dbfactory = DynSQL::getFactory('MySQL');
$dbfactory->setHost('localhost');
$dbfactory->setUser('root');
// $dbfactory->setPasswd();
$dbfactory->setDB('mabdd');
// Je manque d'inspiration pour les noms, pour l'instant
$dbfactory->setOption(DynSQL::ATTR_ERRMODE, DynSQL::ERRMODE_EXCEPTION); // Je compte en faire le mode par défaut
$dbfactory->setOption(DynSQL::ATTR_FETCHMODE, DynSQL::FETCH_ASSOC); // idem
$sql = $dbfactory->getConnection();
echo $sql->getDynDriverType(); // PDO ? MySQLi ? API MySQL ?
// Exemple d'utilisation pour SQL*Server
// Détails pas fixés loin de là, c'est juste pour l'illustration
$dbfactory = DynSQL::getFactory('SqlServ');
$dbfactory->setHost('localhost');
$dbfactory->setUser('root');
// $dbfactory->setPasswd();
$dbfactory->setDB('mabdd');
// Je manque d'inspiration pour les noms, pour l'instant
$dbfactory->setOption(DynSQL::ATTR_ERRMODE, DynSQL::ERRMODE_EXCEPTION); // Je compte en faire le mode par défaut
$dbfactory->setOption(DynSQL::ATTR_FETCHMODE, DynSQL::FETCH_ASSOC); // idem
$sql = $dbfactory->getConnection();
echo $sql->getDynDriverType(); // PDO ? MSSQL ? SQLServ ?
`Haku a écrit:
Coucou Darth.
En fait on s'en fout que l'hébergeur aie ou pas activé l'extension dont tu aies besoin, parce que si tu veux bien faire les choses, t'es un peu sensé, dès le départ, avoir un environnement de dev et de prod identique.
En principe, oui, je suis d'accord (et je l'applique). Mais tu connais beaucoup de monde, aux niveaux PHP divers, qui le fait effectivement ? Surtout chez les +/- débutants, on voit surtout des devs avoir une config locale et une autre en prod. (Et si les débutants d'aujourd'hui apprennent à faire les choses proprement, ceux de demain viendront les remplacer. )
`Haku a écrit:
Après ça ne doit pas t'empêcher de mener ton projet à termes, nombres de projets ont été et seront menés pour le simple plaisir.
Ah bah je ne m'embêterais pas avec ça si ça ne me plaisait pas
- Edité par Darth Killer 5 juillet 2014 à 15:25:36
Bonjour tout le monde.
Un ajout intéressant pour un API serait la gestion des comptes multiples et des alias. Je n'ai aucune idée des utilisations que l'on pourrait en faire, mais le fonctionnement s'approcherait plus d'un ORM que d'une interface d'abstraction.
Je vais essayer d'expliquer par un exemple:
Je code un site en local -> Environnement DEV sur localhost
Je le teste en ligne -> Environnement DEV sur site.net
Je le lance en production -> Environnement PROD sur site.net
Je veux que ton API se connecte à un serveur SQL (ou autre) selon le site sur lequel je suis (localhost ou site.net)
-> 127.0.0.1 ou sql.hebergement.net
Je veux aussi que ton API préfixe la base de données qu'il utilise avec dev_ ou rien selon l'environnement (DEV ou PROD)
-> dev_blog et blog
On a donc 4 combinaisons, dont 3 seront utilisées.
Voici un code illustrant une utilisation
<?php
define('ENV', 'PROD'); // Définit l'environnement utilisé
require 'api.php';
// La classe AccountManager gère tous les comptes
$connection = new AccountManager();
// On crée une condition nommée host qui détermine l'hôte (localhost ou site.com)
$connection->addCondition('host', $_SERVER['HTTP_HOST']); // (note: HTTP_HOST est obligatoire, sinon apache lance une erreur 400)
// Et une autre qui détermine la base de données
$connection->addCondition('env', ENV);
// On ajoute les comptes
$connection->addAccount('host', 'localhost', '127.0.0.1', 'root', ''); // Si HTTP_HOST == localhost, alors le serveur est 127.0.0.1, user/mdp = root/null
$connection->addAccount('host', 'site.net', 'sql.hebergement.net', 'site', 'mdp') // Idem
// Et les bases de données
$connection->addDatabase('env', 'PROD', 'blog'); // Si ENV == PROD, on utilise la bdd `blog`
$connection->addDatabase('env', 'DEV', 'dev_blog'); // Si ENV == DEV, on utilise la bdd `dev_blog`
$user = $connection->getAccount(); // Renvoie les identifiants dans une StdClass
// On se connecte au serveur
$db = new Db($user->server, $user->name, $user->password, $user->database);
// On fait une requête
$statement = $db->query('SELECT * FROM news');
// ...
Voila, voila, j'espère avoir été lu et compris
Merci, geeex
geeex : si je comprends bien, la gestion via une liste de configuration d'une liste d'identifiants pour la connexion à la base de données ? J'avais effectivement un mécanisme de fichier de config en tête comme possibilité (pour ne pas inscrire les identifiants en dur dans le code. C'est moche. ), donc ceci est l'évolution logique. J'en prends note, merci.
Honnêtement c'est beaucoup de chipots pour grand chose. Mais à priori c'est la mode ces dernières années d'empiler solution palliative sur solution palliative au lieu de s'attaquer à la source du problème. Et s'assurer qu'on aura le driver pdo dont on a besoin de façon pérenne, c'est vraiment pas une grande difficulté.
{Sondage} Fonctionalités PHP/SQL utilisées ?
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?