Como programar una aplicación para que trabaje con sqlserver y mysql?

[kotosh]

Se que el titulo es algo desfasado, pero actualmente estamos desarrollando una aplicacion de gestion, y hay necesidad de programar una aplicacion que permita usar cualquiera de las dos bases de datos, segun los gustos y billetera del cliente.

Por alli habiamos considerado usar LINQ, pero con eso nos olvidariamos de los store procedures que son necesarios para darle rapides a nuestra aplicacion que por cierto es una aplicacion que trabajara con una base de datos remota vía web.

Alguna idea que me permita abstraer la DB?

Gracias por su ayuda

[gnzsoloyo]

Existen al menos dos caminos, uno eficiente y efectivo, y el otro algo flexible, pero limitado.
Por un lado aclaremos: no hay forma de abstraer completamente el DBMS que usas desde el momento que cada uno de ellos provee de recursos distintos y sintaxis extendida para la versión de SQL. En este sentido, el problema es que tanto los SP como las propias consultas son limitantes a la hora de tratar de hacer una aplicación que pueda funcionar con ambos modelos de base de datos, además de que los SP no son portables entre las plataformas.
La forma mas efectiva y eficiente de esto es en realidad crear una un objeto que concentre la funcionalidad de comunicación con la base de dtos, y que ese objeto pueda ser una instancia de una clase que maneje o SQL Server o MySQL; esto quiere decir que hay que crear dos clases, una para cada uno, con los mismos métodos, los mismos parámetros en cada método, pero que cada uno contenga los recursos propios de esos motores.
No es tan impensable ni tan difícil. El único problema (aparte de migrar el código de cada uno) es que también necesitas construir dos moddelos físicos a implementar por scripts distintos. Uno por DBMS.
Esto último lo puedes hacer con herramientas de diseño, como Enterprise Architect. Con ellas, crear el script de una base sobre un diseño, para cada DBMS es sencillo.
Esta es la técnica que nosotros implementamos.

La otra solución es trabajar con un codigo absolutamente ANSI-SQL, que es portable, pero en ese caso olvídate de los SP, o ls deberás duplicar...

[dwaks]

Acá te hablaré más de un concepto viejo que se usa mucho que es el Mapeo objeto-relacional:
http://es.wikipedia.org/wiki/Mapeo_objeto-relacional

Esto separá la lógica de negocio para que el programa no dependa de una base de datos sino de objetos, lee el link de arriba.

Yo en lo personal uso 2 librerias muy buenas que son ibatis y NHibernate:

IBATIS
http://ibatis.apache.org/
Ejemplo de uso: http://opensource.atlassian.com/conf...ck+Start+Guide

NHIBERNATE
https://www.hibernate.org/343.html
Ejemplo de uso: https://www.hibernate.org/hib_docs/n...ickstart-intro

En mi caso como se trabaja con Arquitectos, Desarrolladores y Encargado de Base de datos cada uno tiene su funcionalidad y el programa se basa 100% en orientación a objeto lo que nos lleva al uso de esta tecnología para que los de base de datos nos faciliten las cosas.

Saludos,

[gnzsoloyo]

Las dos herramientas mencionadas cumplen precisamente el papel que proponía yo más arriba: Son frameworks que permiten separar la aplicación de la capa de datos.
El problema que persiste es que los modelos de datos y los SP se deben construir separadamente, ya que tanto una herramienta como otra lo que proveen son los accesos a datos, pero la customización de las consultas no son realizadas por ellas.
En otras palabras, el problema de la sintaxis no portable entre los motores subsiste...
En el caso de Hibernate, sólo da soporte a los SP de SQL Server, no así a los de MySQL (ni a las subconsultas, lo que es crítico).
En el caso de ibator, este ejemplo muestra cómo una sentencia no es generada por el ibator, sino como código customizado...
Yo insisto en un tema: El problema no es acceder a las bases de datos. Eso se puede resolver hasta con vb.Net usando ADO. El problema es cómo resolver la portabilidad del SQL entre ambos motores, ya que estas herramientas no tienen esa capacidad, y es en el SQL donde las bases de datos muestran su verdadero poder.

[dwaks]

Todo depende a la hora de crear en papel el desarrollo de el software basado en lo que se quiere como producto final y sus limitantes.

El agente de base de datos que se use no es problema para nada. Si te das cuenta los que usan StoreProcedure son las empresas que tienen más de 1 programa que accese la información. Pero como digo no ahy nada que se tenga que consultar de una Base de datos que el query normal no pueda, sino mira como php 4.x.x se hizo famoso con mysql 4.x.x y Mysql no usaba siquiera StoreProcedure.

Todo es la base de lo que se debe hacer y teniendo todo en Objetos no ahy nada que no se pueda manipular desde el mismo programa para eso el Mapeo relacional.

Las variantes entre Sql de una base de datos con otra es más a nivel de funciones y debido a esto es que la responsabilidad de manipulación de la información se hará desde el programa. Se puede decir que abrá más trabajo pero al final con un producto como el que ellos quieren hacer multiplataforma que con una cadena de Conección cambie la base de datos ya ganaron porque no se debía hacer 2 programas separados cada uno usando las ventajas propias de una Base de Datos y es lo que normalmente hacen las empresas de programas.

Si el proyecto tiene presupuesto y tiempo para hacer una plataforma para cada base de datos entonces se hace separado, sino tiene tiempo ni presupuesto para separar eso, entonces también ahy solución que costará sacrificar las facilidades de cada Agente de Base de Datos y manipular todo desde el programa (Cosa que no afecta nada si se hace todo bien).

Saludos,