Abstraction de la base de données - prenant en charge plusieurs syntaxes

Question

Dans un projet PHP sur lequel je travaille, nous devons créer des extensions DAL pour prendre en charge plusieurs plates-formes de bases de données. Le principal piège que nous avons avec ceci est que les différentes plates-formes ont des syntaxes différentes. MySQL et MSSQL sont remarquables.

Quelle serait la meilleure solution à cela?

Voici un couple dont nous avons discuté:

Construction SQL basée sur des classes

Ceci impliquerait la création d'une classe qui vous permette de construire des requêtes SQL bit par bit. Par exemple:

$stmt = new SQL_Stmt('mysql');
$stmt->set_type('select');
$stmt->set_columns('*');
$stmt->set_where(array('id' => 4));
$stmt->set_order('id', 'desc');
$stmt->set_limit(0, 30);
$stmt->exec();

Cela implique cependant pas mal de lignes pour une seule requête.

Reformatage de la syntaxe SQL

Cette option est beaucoup plus propre - elle lirait le code SQL et le reformaterait en fonction des langues d'entrée et de sortie. Je peux toutefois constater que cette solution est beaucoup plus lente en ce qui concerne l'analyse.

Answer 1

Je recommanderais la construction SQL basée sur les classes et Doctrine , Zend_Db ou MDB2 . Et oui, s’il faut plus de lignes pour écrire des sélections simples, mais au moins vous pouvez vous fier à un analyseur et n'avez pas besoin de réinventer la roue.

L’utilisation de toute DBAL est un compromis entre la vitesse, et pas seulement l’exécution de la base de données, mais la première fois que vous utiliserez l’une ou l’autre de ces méthodes, ce sera plus pénible que lorsque vous la maîtriserez vraiment. De plus, je suis presque à 100% sûr que le code généré n'est pas la requête SQL la plus rapide, mais c'est le compromis que je voulais dire plus tôt.

En fin de compte, c'est vous qui décidez. Même si je ne le ferais pas et que ce n'est pas impossible, la question demeure de savoir si vous pouvez réellement économiser du temps et des ressources (à long terme) en implémentant votre propre DBAL.

Answer 2

Une solution pourrait être d’avoir différents ensembles de requêtes pour différentes plates-formes avec des identifiants comme

MySql: GET_USERS = "SELECT * FROM users"

MsSql: GET_USERS = ...

PgSql: GET_USERS = ...

Ensuite, au démarrage, vous chargez l'ensemble de requêtes nécessaire et faites référence ensuite

Db :: loadQueries (plateforme):

$ users = $ db- > requête (GET_USERS)

Answer 3

Un tel schéma ne prendrait pas en compte toute la richesse offerte par SQL. Vous feriez donc mieux d'utiliser des procédures stockées générées par du code pour toutes vos tables et pour chaque base de données.

Même si vous utilisez des procédures stockées paramétrées qui sont plus sensibles au modèle de base de données (c'est-à-dire qu'elles se joignent ou sont sensibles à l'utilisateur et sont donc optimisées pour chaque fournisseur), c'est toujours une excellente approche. Je considère toujours que la couche d’interface de base de données fournit plus que de simples tableaux à l’application, car cette approche peut nécessiter beaucoup de bande passante et générer des gaspillages aller-retour.

Answer 4

si vous avez un ensemble de serveurs qui le supporte, je conviens que la meilleure méthode consiste à générer des procédures stockées pour former un contrat. Cependant, cette approche ne fonctionne pas si vous avez un back-end dont les capacités sont limitées en ce qui concerne les procédures stockées, auquel cas vous créez une couche d'abstention pour implémenter SQL ou générez un sql spécifique à une cible basé sur une syntaxe sql abstraite / limitée.