¿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 |
Cita:
Cita:
|
Cita:
https://techcommunity.microsoft.com/...et/ba-p/315933 https://docs.microsoft.com/en-us/sql...ectedfrom=MSDN Cita:
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.... |
Cita:
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. |
Cita:
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 Cita:
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.. |
Cita:
Cita:
|
Cita:
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! |
La franja horaria es GMT +2. Ahora son las 14:41:04. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi