Crear aplicaciones que funcionen con DBMS diferentes

"Javier Lozano" wrote in message
news:
Mostrar la cita

Uno de los paradigmas que enfrentamos los desarrolladores es poder crear
una aplicacion que funcione con diferentes motores de basos de datos, por
ejemplo, me gustaria hacer una aplicacion que funcione con SQL Server, con
DB2
Express y con Oracle. No se como enfrentar esto, por eso solicito su
ayuda:

1- Es viable (lease rentable), mas alla del punto de vista teorico, si no
desde un enfoque basado en la vida real, llevar a cabo un proyecto de ese
tipo?

Es viable, pero costoso. Aunque hay soluciones tales como usar OleDb o
IDBConnection, hay que tener cuidado al programar para no utilizar ninguna
característica de base de datos que sea exclusiva de una base de datos
concreta. Y a veces las diferencias no son evidentes. Por ejemplo, si haces
el desarrollo contra Oracle y utilizas una columna de tipo Unique que admita
nulls, y escribes el programa de forma que grabe null en esa columna en
varios registros de esa tabla, si luego cambias la base de datos a Sql
Server el programa fallará porque Sql Server sólo admite un único null en
las columnas Unique.


Mostrar la cita

2- En cuanto a costos, la creacion y posterior mantenimiento de la
aplicaicon implicaria mas costos operativos($$$)

Sí, es considerablemente más costoso. En el pasado mi empresa desarrolló
una aplicación que funcionaba con varias bases de datos, y el coste de
mantenimiento era tan elevado que en nuevos desarrollos hemos optado por
soportar una única base de datos.


Mostrar la cita

3- Entiendo que seria dificil mantener el mismo store procedure en todas
las bases de datos, sea por temas de sintaxis, sea por aprovechar
caracteristicas particulares de cada base de datos, etc.

Por temas de sintaxis, los procedimientos no son compatibles entre
distintas bases de datos. Tuve una aplicación que llamaba a procedimientos
almacenados en T-SQL cuando funcionaba contra Sql Server, PL-SQL cuando iba
contra Oracle, y cuando funcionaba contra otra base de datos distinta, no
utilizaba procedimientos almacenados sino que realizaba todas las
operaciones mediante código cliente. Como puedes imaginarte, el coste de
desarrollo, test, y mantenimiento de estas tres variantes era muy elevado.

Gracias Alberto

Tus respuestas confirman mis analisis preliminares, con lo cual mis dudas se
reducen a lo siguiente :

Ya que crear una aplicacion con multiples bases de datos resulta mas viable
en el terreno teorico que en el terreno de produccion real, necesito proveer
a mis clientes de un base de datos que sea realmente FREE pero sin las
restricciones de un SQL Server Express u Oracle Express. Se tambien que
MySQL y otras DB open source no resultan 100% free. Sin embargo, segun el
EULA de DB2 Express, esta si que es una base de datos realmente libre y sin
restricciones, creo que esta sería la candidata principal.

Por otro lado, estuve reviando las nuevas capacidades de SQL Server 2008,
tales como los nuevos tipos de datos Geography, Geometric, Hierarchy Id. Y
la nueva capacidad de pasar tablas como parametros a un store procedure
(fabuloso para pasar el detalle de una factura), capacidad de encriptar
columnas y tablas,etc. Todas esas nuevas caracteristicas haran el desarrollo
mas eficiente y rapido. Esto estara incluido en SLQ Server Express 2008,
pero con la restriccion de 4GB :-(.

Por todas esas caracteriscas, SQL Server 2008 tambien es un candidato a
tener en cuenta. Agradezco de antemano todos sus comentarios y
recomendaciones.

Javier Lozano
Lima-Peru



"Alberto Poblacion" wrote
in message news:
Mostrar la cita

"Javier Lozano" wrote in message
news:
Mostrar la cita

Uno de los paradigmas que enfrentamos los desarrolladores es poder crear
una aplicacion que funcione con diferentes motores de basos de datos, por
ejemplo, me gustaria hacer una aplicacion que funcione con SQL Server,
con DB2
Express y con Oracle. No se como enfrentar esto, por eso solicito su
ayuda:

1- Es viable (lease rentable), mas alla del punto de vista teorico, si no
desde un enfoque basado en la vida real, llevar a cabo un proyecto de ese
tipo?

Es viable, pero costoso. Aunque hay soluciones tales como usar OleDb o
IDBConnection, hay que tener cuidado al programar para no utilizar ninguna
característica de base de datos que sea exclusiva de una base de datos
concreta. Y a veces las diferencias no son evidentes. Por ejemplo, si
haces el desarrollo contra Oracle y utilizas una columna de tipo Unique
que admita nulls, y escribes el programa de forma que grabe null en esa
columna en varios registros de esa tabla, si luego cambias la base de
datos a Sql Server el programa fallará porque Sql Server sólo admite un
único null en las columnas Unique.


Mostrar la cita

2- En cuanto a costos, la creacion y posterior mantenimiento de la
aplicaicon implicaria mas costos operativos($$$)

Sí, es considerablemente más costoso. En el pasado mi empresa
desarrolló una aplicación que funcionaba con varias bases de datos, y el
coste de mantenimiento era tan elevado que en nuevos desarrollos hemos
optado por soportar una única base de datos.


Mostrar la cita

3- Entiendo que seria dificil mantener el mismo store procedure en todas
las bases de datos, sea por temas de sintaxis, sea por aprovechar
caracteristicas particulares de cada base de datos, etc.

Por temas de sintaxis, los procedimientos no son compatibles entre
distintas bases de datos. Tuve una aplicación que llamaba a procedimientos
almacenados en T-SQL cuando funcionaba contra Sql Server, PL-SQL cuando
iba contra Oracle, y cuando funcionaba contra otra base de datos distinta,
no utilizaba procedimientos almacenados sino que realizaba todas las
operaciones mediante código cliente. Como puedes imaginarte, el coste de
desarrollo, test, y mantenimiento de estas tres variantes era muy elevado.

Javier Lozano wrote:
Mostrar la cita

Saludos compañeros

Uno de los paradigmas que enfrentamos los desarrolladores es poder crear una
aplicacion que funcione con diferentes motores de basos de datos, por
ejemplo, me gustaria hacer una aplicacion que funcione con SQL Server, con
DB2
Express y con Oracle. No se como enfrentar esto, por eso solicito su ayuda:

1- Es viable (lease rentable), mas alla del punto de vista teorico, si no
desde un enfoque basado en la vida real, llevar a cabo un proyecto de ese
tipo?

2- En cuanto a costos, la creacion y posterior mantenimiento de la
aplicaicon implicaria mas costos operativos($$$)

3- Entiendo que seria dificil mantener el mismo store procedure en todas las
bases de datos, sea por temas de sintaxis, sea por aprovechar
caracteristicas particulares de cada base de datos, etc.

4- Por favor comentar cualquier experiencia al respecto o tal vez
bibliografia especializad.


Gracias anticipadas

Javier Lozano
Lima-Peru

Hola Javier,

he tenido mucha experiencia en este tipo de desarrollos. Y a mí me ha
ido bastante, bastante bien, empleando ODBC y C++. Tengo varias
aplicaciones que las diseñamos con SQL Server u Oracle en mente, pero
que sin problemas algunos clientes han empleado MySQL e inclusive
PostgreSQL. Por supuesto, hay que adherirse a la especificación SQL de
ODBC. En el caso de .NET, existen estas mismas clases, System.Data.Odbc,
pero supongo que no habría mucha diferencia con respecto a OleDB.

Obviamente es muy difícil, aunque no imposible, intentar soportar DBs
grandes contra las Desktop (DBase, FoxPro, Access).

Con respecto a los stored procedures... ahí sí ni cómo hacerle. La
verdad es que yo raramente los empleo (no me gusta separar la lógica de
la aplicación del binario y pasar capas extras a la base de datos), pero
pues eso depende ya no de SQL, sino de TSQL en SQLServer, de PL/SQL en
Orcale, etc. Ya es específico de la base de datos, así que en ese caso
la portabilidad se ve totalmente reducida a nada (claro que, con
respecto a tu aplicación, sería muy transparente, pero habría que
soportar los cambios al DataLayer en la DB).

Finalmente, si buscas una base de datos realmente Free y con
relativamente buen soporte para ser OpenSource (hasta tiene sus
librerías para .NET), revisa un poco PostgreSQL. No te cuesta un solo
centavo y es muy grande y eficiente, e inclusive el "footprint" es muy
bajo.

Saludos.