Problema
Los clientes no querían renunciar a su motor de base de datos, pero el producto no podía permitirse tener dos ramas separadas o dos formas de pensar la misma funcionalidad.
Caso 02 · Compatibilidad
SQL Server ↔ MariaDB
Este caso trataba de algo muy práctico: mantener una sola base de código que funcionara bien con dos motores de base de datos distintos, sin duplicar lógica cada vez que aparecía una diferencia.
Contexto
La presión real no venía de la capa técnica, sino del mantenimiento. Cada diferencia entre motores podía acabar convertida en un bug difícil de perseguir si no se diseñaba bien desde el principio.
La clave era asumir que la compatibilidad no es una capa secundaria, sino parte del producto.
Arquitectura
- Separé las diferencias de motor en una capa fina de adaptación.
- Las reglas de negocio se mantuvieron comunes.
- Las consultas sensibles se trataron de forma explícita, no “a ver si cuela”.
- Las pruebas se diseñaron para detectar desviaciones reales entre motores.
Resultado
La base de código dejó de dividirse por motor y el equipo pudo trabajar con una estructura estable. Eso redujo ruido, incidencias y discusiones innecesarias sobre “la versión de cada cliente”.