¿Y si haces que tu sistema trabaje con múltiples motores? Es decir, de base que trabaje con Firebird pero que también puedan usar MySQL, PgSQL, MsSQL y así.

Aunque depronto es complicarlo mucho si es algo sencillo pero es buena opción pensando en el escalamiento y que cada cliente puede querer usar cierto motor que su jefe de IT les ha recomendado muchisimo

Según entiendo, es uno de los propósitos de diseñar tu sistema en 3 capas, ser independiente del motor de bases de datos...

Que siento que se complica más porque cada motor de base de datos tiene sus peculiaridades que impide hacer una serie de sentencias "de norma" adaptables a cada uno..., cosas raras de la informática, lo que debería ser standard es lo que más cambia.

Esto es noticia vieja. JET fue marcado como "obsoleto" hace como 16 Años.

https://techcommunity.microsoft.com/...et/ba-p/315933
https://docs.microsoft.com/en-us/sql...ectedfrom=MSDN

Y antes de eso, Jet era muy bien conocido como un producto pésimo.

No tiene ningun sentido usar Jet, sabiendo que sqlite (por nombrar el reemplazo mas obvio) barre con este y ademas esta mejor probado.

P.D: Desde el punto de vista de MS, Jet es idéntico a paradox: Una reliquia del pasado. Y si te preguntas "Y eso no pues que esta en Access?" pues veras, Access lo tienen hay medio vivo pues porque aja, pero que le tengan cariño? Para nada. Por eso, si realmente le dieran importancia, le QUITARIAN JET DE UNA. Pero como no es asi y no les importa, pues aja, ahi ta*.

No sean como MS con jet, ok?

P.D.2: En mi modo conspirativo, MS mato FoxPro porque era demasiado bueno, y Access esta en modo zombie, porque ambos representan un estilo de desarrollo de apps de negocio DEMASIADO productivo y que hacia innecesario meter C++, C# y demas....

Esa es una de las falacias de desarrollo empresarial más inmensas que hay. De ahi salen otras falacias como "no usemos vistas, ni procedimientos almacenados ni triggers" y demas ideas raras.

Eso es como decir "y porque no escribes en Java como si fueras a usar despues C#, igual son como lo mismo, no?"

P.D: Soporte a multiples DBs tiene sentido para componentes de integracion o drivers generales, de resto? Nope!

También dBase era bueno y no por ello se le aconseja a nadie hoy en día.
En 1998 hice mi primer proyecto profesional con Delphi y Firebird (Interbase, pues Firebird creo que es de 1999 y lo cambié en cuanto salió), y ya entonces se descartó "ms access", dbase, paradox y otros similares porque eran antiguos, propensos a fallos y con muy mal funcionamiento en red.
Así que si en 1998 eran antiguos, unos 22 años después para qué hablar.

Hace 16 años (cuando acababa de salir Delphi 7) todavía programabamos con el BDE y ADO+Jet4 era mucho mejor (a mi entender).

He programado en Delphi6 contra Oracle, SQLServer, MDB's, Paradox, Interbase y alguna cosa más.
Los 2 primeros estaban en otro nivel y para según qué cosas a mi entender no tiene sentido "montarlos" y de los siguientes (en su momento) lo mejor era ADO+Jet4+MDB de largo. Y no me baso en ningun artículo lo se por experiencia propia.
Hoy está claro que IB/FB estarían en la primera categoría (SGBD's) y el resto no tienen ese calificativo

No se qué punto de vista tiene en MS, pero el trabajo con ambos no tiene nada que ver.

Sigo pensando que todo depende, hay 1000 formas de almacenar datos, desde el registro, ficheros INI, ficheros planos, XML, JSON, formatos nativos, SGBD's, modelos relacionales, no relacionales, Bases de datos noSQL y todos los demás que se nos puedan ocurrir y ninguno es malo o bueno, cada uno es el adecuado para una tarea. Al menos es lo que yo pienso..

Hoy y antes, pues ya existían en la fecha que comentas.


Eso es cierto.

Mientras entiendo lo que dices, siempre me ha molestado lo de decir que "ninguna opción es mala", al defender tecnologías y similares. Eso no tiene sentido. Hay opciones que sí son malas: C, C++, Js, PHP, paradox, jet son malas opciones. Y en el caso de un almacenamiento de datos, cualquier cosa que sea viable de corromper o meter datos malos, es mala. Por eso, mongodb, jet, fox, etc es malo.

Uno en este trabajo le toca convivir con malas opciones todo el tiempo. Que dadas las circunstancias a punta de sudor (y muchas veces, pura suerte) eso se maneja? Pues eso es lo que hace a alguien profesional. Que si toca remangarse las mangas y poner a andar el motor a punta de cinta aislante echandole manualmente el agua pa que no se recaliente, pues aja, eso es lo que toca.

Pero habiendo MEJORES opciones? Y ademas, ante la EXPLICITA recomendación del fabricante? Y luego de AÑOS? Eso es puro masoquismo. Y en esta industria SOMOS masoquistas.

Ej: Ahorita mismo tengo que integrar contra un bodrio de bd de datos MySQL cuyas tablas (que es un erp) se llaman UNCC_0001, UNCC_0002 ...., obvio UNCC_00021 es pedidos. Y sus campos se llaman FT_0001, FT_0002 ... que obvio FT_0001 es la PK de la tabla.

El cliente dice que ese ERP funciona muy bien!