Debido a que todos los servidores SQL implementan diferentes partes del estándar SQL, toma trabajo escribir aplicaciones SQL portables. Es muy fácil obtener portabilidad para selects muy simples y para inserts, pero es más difícil cuantas más funcionalidades se requieran. Obtener una aplicación que sea rápida en varios sistemas de bases de datos, es una tarea muy difícil.

Para hacer aplicaciones complejas portables, necesita determinar para cuáles servidores SQL debe trabajar, después determinar qué características soportan esos servidores.

Todos los sistemas de bases de datos tienen algunos puntos débiles. Esto es, tienen diferentes concesiones de diseño que conducen a comportamientos diferentes.

Puede usar el programa de MySQL crash-me para encontrar funciones, tipos y límites que puede usar con una selección de servidores de bases de datos. crash-me no comprueba cada posible característica, pero es razonablemente completo, puesto que hace cerca de 450 pruebas.

Un ejemplo de un tipo de información de la que el programa crash-me puede proveer es que no debería usar nombres de columnas que sean mayores de 18 caracteres si quiere que la aplicación funcione en Informix o DB2.

El programa crash-me y MySQL benchmarks son independientes de la base de datos. Mirando por encima cómo están escritos, puede hacerse una idea de qué debe hacer que sus propias aplicaciones sean independientes de bases de datos. Los programas se encuentran en el directorio sql-bench dentro del código fuente de la distribución de MySQL. Estan escritos en Perl y usan la interfaz para bases de datos DBI. Usar DBI ya soluciona una parte de los problemas de portabilidad puesto que provee de métodos de acceso independientes a las bases de datos.

Ver http://dev.mysql.com/tech-resources/benchmarks/ para los resultados de las mediciones.

Esforzarse para ser independiente del motor de bases de datos, implica prestar atención a los cuellos de botella de cada servidor SQL. Por ejemplo, MySQL es muy rápido obteniendo y actualizando registros para tablas MyISAM, pero tiene un problema mezclando lecturas y escrituras lentas sobre la misma tabla. Por otra parte, Oracle tiene un enorme problema cuando intenta acceder a registros que se han actualizado recientemente (hasta que se escriben en el disco). Las bases de datos transaccionales en general no son muy buenas generando resúmenes de tablas desde las tablas de registro (log), puesto que en este caso el bloqueo (lock) de registros es casi inútil.

Para hacer una aplicación realmente independiente de la base de datos, se necesita definir una interfaz fácilmente extendible a través de la cual se manipularán los datos. Puesto que C++ está disponible en la mayoría de los sistemas, tiene sentido usar una interfaz basada en clases de C++ hacia la base de datos.

Si usa alguna característica que es específica de algún sistema de base de datos (por ejemplo la sentencia REPLACE, que es específica en MySQL), debería implementar la misma característica para otros servidores SQL codificando un método alternativo. Aunque la alternativa sea más lenta, permite que la misma tarea se haga en otros servidores.

Con MySQL, puede usar la sintaxis /*! */ para agregar algunas palabras claves de MySQL a una consulta. El código dentro de /**/ es tratado como un comentario (e ignorado) por la mayoría de los otros servidores SQL.

Si el alto rendimiento es más importante que la exactitud, como en algunas aplicaciones Web, es posible crear una capa de la aplicación que almacene en una cache todos los resultados para obtener un rendimiento mejor. Dejando que los resultados viejos expiren en determinado tiempo, puede mantener la cache razonablemente actualizado. Éste es un método para soportar picos de carga, al que se añade la posibilidad de implementar un incremento dinámico de la cache y un aumento del tiempo de expiración, hasta que las cosas regresen a la normalidad.

En este caso, la información de creación de la tabla debe contener información del tamaño inicial de la cache y de la frecuencia de refresco de la tabla.

Una alternativa para implementar una aplicación en cache es usar la cache para consultas de MySQL. Habilitando la cache para consultas, el servidor toma los detalles de las consultas determinando qué resultados pueden ser reutilizados. Esto simplifica la aplicación. Ver Sección 5.12, “La caché de consultas de MySQL”.