¿Soy el único que consulta más de una base de datos?

Después de leer mucho sobre Ruby on Rails y múltiples conexiones de base de datos, parece que he encontrado algo que no mucha gente, al menos no con ror. Estoy acostumbrado a consultar muchas bases de datos y esquemas diferentes y a retirar la información para un informe o para una sola página. Por lo tanto, un usuario no tiene que iniciar sesión en varios sistemas diferentes. Puedo crear una página que tenga todos los sistemas en una o dos páginas web.

¿No es una ocurrencia normal en la web y en el diseño basado en bases de datos?

EDIT: ¿Esto es porque la mayoría de mi código original está en asp clásico?

Realmente creo que la mayoría de los diseñadores de ORM no parecen tener en cuenta que los usuarios pueden querer tener en cuenta más de una base de datos. Esto parece ser una limitación bastante común en el universo ORM.

El sitio web de nuestro cliente se ejecuta en 3 bases de datos, así que hago esto para. En realidad, estoy condensando todo en vistas desde una base de datos central que luego se conecta con las otras.

Sin embargo, nunca consideré que este sea un comportamiento “normal”. Supongo que la mayoría del tiempo estarías diseñando para un sistema y trabajando en contra de eso.

EDIT: Solo para elaborar, usamos Linq to SQL para nuestra capa de datos y definimos los objetos contra las vistas de la base de datos. De esta manera, mantenemos los informes y el código de aplicación trabajando con el mismo modelo de datos. Hay un poco de trabajo adicional para configurar las entidades Linq, porque tiene que definir manualmente las claves primarias y configurar las asociaciones … sin embargo, hasta ahora, definitivamente ha valido la pena. Tratamos de hacerlo con Entity Framework, pero tuvimos muchos problemas para establecer las relaciones de manera adecuada y tuvimos que abandonar. Lo gracioso es que pensé que Entity Framework se suponía que estaba diseñado para escenarios más avanzados como el nuestro …

No es infrecuente golpear varias bases de datos durante una sola parte del flujo de trabajo de una aplicación. Sin embargo, en cada instancia que lo he hecho, esto se ha realizado a través de varias llamadas de servicio web, que entre otras cosas envuelven las bases de datos en cuestión.

Según mi conocimiento, nunca he tenido la necesidad de atacar varias bases de datos directamente a la vez y combinar los resultados en un solo informe.

He visto este tipo de architecture en los portales corporativos, donde se extraen muchos datos a través de diferentes fonts de datos. El objective principal de un portal es juntar los sistemas con silos; es posible que los usuarios no quieran usar muchos sistemas de forma aislada (especialmente si tienen que iniciar sesión en cada uno). En ese tipo de escenario es normal, especialmente si se trata de una compañía grande que se ha expandido rápidamente y tiene una gran cantidad de sistemas heterogéneos.

En su caso, si esto es lo correcto, depende del motivo por el que tenga estos DB separados.

Con los ORM puede ser un poco difícil. Sin embargo, se puede hacer. Extraiga los objetos según sea necesario de las distintas bases de datos, luego utilícelos como un compuesto para crear un nuevo objeto que sea el real que se desea. Si puede omitir la parte ORM del proceso, puede consultar directamente las bases de datos y construir su objeto directamente.

La recostackción de datos de dos bases de datos y la comstackción de un informe no es infrecuente, pero como el motor de consultas de cualquiera de las bases de datos no puede optimizar las consultas entre bases de datos, los sistemas OLTP generalmente usan una sola base de datos para mantener la aplicación en funcionamiento.

Si construye el sistema desde cero, no es recomendable hacerlo de esta manera. Si está trabajando con un sistema que no diseñó, no hay muchas opciones y no es infrecuente (esa es la diferencia entre el crecimiento “orgánico” y el “planificado”).

Sin contar el master y varias instancias de prueba, llegué a nueve bases de datos de forma regular. Sí, lo heredé, y sí, el ASP “clásico” ocupa un lugar destacado. Por supuesto, todos los diseñadores “shinys” de este lío han desaparecido. Lo estamos reemplazando con cosas más sanas tan rápido como podamos.

Pensaría que si está construyendo un nuevo sistema y continúa agregando bases de datos y llegando al punto de dos o tres bases de datos, es probable que sea el momento de repensar su diseño. OTOH, si está agregando datos de múltiples sistemas dispares, entonces, no, no es tan extraño. Dependiendo de la puntualidad que necesite, y de su presupuesto para lanzar el hardware al problema, y ​​si sus datos son en su mayoría estáticos, este sería un buen escenario para un “servidor de informes” que extrae los datos del servidor de Live periódicamente.