Abstracción de base de datos - soportando múltiples sintaxis

Question

En un proyecto de PHP en el que estoy trabajando, necesitamos crear algunas extensiones DAL para soportar múltiples plataformas de bases de datos. El principal inconveniente que tenemos con esto es que las diferentes plataformas tienen diferentes sintaxis: MySQL y MSSQL notables son bastante diferentes.

¿Cuál sería la mejor solución para esto?

Aquí hay una pareja que hemos discutido:

Creación de SQL basada en clases

Esto implicaría crear una clase que le permita construir consultas SQL bit a bit. Por ejemplo:

$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();

Sin embargo, involucra bastantes líneas para una sola consulta.

Reformateo de sintaxis SQL

Esta opción es mucho más limpia: leería el código SQL y lo reformatearía según los idiomas de entrada y salida. Sin embargo, puedo ver que esta es una solución mucho más lenta en lo que respecta al análisis.

Answer 1

Recomiendo la construcción de SQL basada en clases y recomiendo Doctrine , Zend_Db o MDB2 . Y sí, si requiere más líneas para escribir selecciones simples, pero al menos puede confiar en un analizador y no necesita reinventar la rueda.

El uso de cualquier DBAL es un compromiso en la velocidad, y no solo la ejecución de la base de datos, sino que la primera vez que use cualquiera de ellos será más doloroso que cuando está realmente familiarizado con él. Además, estoy casi 100% seguro de que el código generado no es la consulta SQL más rápida, pero esa es la compensación que quería decir anteriormente.

Al final, depende de usted, así que aunque no lo haría y no es imposible, la pregunta sigue siendo si puede ahorrar tiempo y recursos (a largo plazo) implementando su propio DBAL.

Answer 2

Una solución podría ser tener diferentes conjuntos de consultas para diferentes plataformas con identificadores similares a algo como

MySql: GET_USERS = " SELECT * FROM users "

MsSql: GET_USERS = ...

PgSql: GET_USERS = ...

Luego, al iniciar, carga el conjunto necesario de consultas y luego se refiere

Db :: loadQueries (plataforma):

$ users = $ db- > query (GET_USERS)

Answer 3

Tal esquema no tomaría en cuenta toda la riqueza que ofrece SQL, por lo que estaría mejor con los procedimientos almacenados generados por código para todas sus tablas para cada DB.

Incluso si utiliza procedimientos almacenados parametrizados que son más conscientes del modelo de base de datos (es decir, hacen uniones o son conscientes del usuario y, por lo tanto, están optimizados para cada proveedor), sigue siendo un gran enfoque. Siempre veo que la capa de interfaz de la base de datos proporciona más que simples tablas a la aplicación, ya que ese enfoque puede ser un uso intensivo del ancho de banda y desperdiciar el viaje.

Answer 4

si tiene un conjunto de backends que lo respalden, estoy de acuerdo en que generar procedimientos almacenados para formar un contrato es el mejor enfoque. Sin embargo, este enfoque no funciona si tiene un backend con capacidad limitada con respecto a los procedimientos almacenados, en cuyo caso construye una capa de abstención para implementar SQL o generar un sql específico de destino basado en una sintaxis de sql abstracta / limitada.