none
Ayuda con duda... RRS feed

  • Pregunta

  • Bueno lo que quiero es resolver es una duda que tengo respecto a un sistema con el que me estoy topando... y es que la forma como esta compuesta me causa extrañeza ya que esta organizada de una forma un tanto peculiar (para mi porque nunca había visto algo así).

    El sistema utiliza 5 bases de datos en sql server 2008 EE de la siguiente forma:

    - la primera bd (y sólo esta) tiene todos los procedimientos almacenados desde los cuales se realizan todas las operaciones sobre las otras bases de datos (2,3,4,y 5), ninguna otra bd tiene procedimientos almacenados.

    - La segunda base de datos tiene tablas que podríamos llamarlas de "configuración del sistema" ya que almacena datos iniciales del sistema (20 tablas aprox).

    - La tercera base de datos tiene tablas algo más comunes en el sistema ya propias de la lógica del negocio,en este caso una entidad recaudadora de impuestos (150 tablas aprox.)

    - La cuarta base de datos tiene 8 tablas, sobre las cuales se realizan operaciones constantemente (mucho mas que en las otras tablas).

    - La quinta base de datos es una base de datos de historial de operaciones(creo que esta bd si es necesaria y entiendo su función) en donde se registra todo la data que ha sido modificada o eliminada de las tablas más relevantes

     

    Mi pregunta es: ¿Existe algún motivo en especial por el que se separa de esa manera,por lo menos de las bds 1,2,3 y 4, quizás por seguridad o por velocidad?

    Cualquier comentario es bien aceptado, y dejo entendido que soy novato en esto y quizás es el motivo de mi extrañeza. Desde ya muchas gracias.


    Just me
    lunes, 4 de julio de 2011 22:45

Respuestas

  • Hola Carlos, en mi experiencia profesional me he topado con algunos casos particulares que no siguen digamoslo el "patron tradicional" en cuanto al diseño y la arquitectura, hay uno en particular que me viene a la mente y es un Sistema de Informacion de una Entidad Bancaria (Core Bancario), en este caso particular debido al alto volumen de transacciones y el esquema de "mercadeo" de la aplicación cada Base de Datos representaba un módulo, asi que podrias tener por ejemplo el siguiente grupo de bases de datos:

    BD_Tesoreria

    BD_Pasivas

    BD_Activas

    BD_Comercio_Exterior

    BD_Clientes

     

    .....

    Y una base de datos con información vinculada a datos de tipo catálogo (monedas, paises, ciudad, etc), por elementos particulares del negocio bancario requerias realizar ciertas operaciones entonces esta separación modular te daba la oportunidad de aplicar ciertas tareas o procesos de forma independiente, con un enfoque mas hacia un producto bancario que al sistema como un todo.

    Cabe destacar que este sistema del cuál te estoy hablando estaba planteada sobre una plataforma un tanto antigua (SQL Server 7.0) y en donde no existian muchos avances y mejoras que actualmente te pueden permitir mitigar ciertos problemas, me vienen a la mente el uso de esquemas y las tablas particionadas. En el caso que planteas por ejemplo la cuarta base de datos (8 tablas frecuentes) perfectamente podria estar contenida en la base de datos operativa(3ra BD), pero con el debido particionamiento, supongo que su separación se debio a la idea de tener un mejor rendimiento sobre tablas de uso intensivo, pero bueno toca "sospecharlo"   :-).

    Espero haber ayudado un poco y bueno cualquier duda estoy a la orden para apoyarte en lo que pueda.

     

    Saludos,

    geek.ms/blogs/ghernandez



    martes, 5 de julio de 2011 0:47
  • Cuando las personas nos ponemos a diseñar, como cuando tomamos cualquier decisión, solemos hacerlo en base a corazonadas, experiencias previas, análisis y buena voluntad.  El único motivo que entiendo que las personas que diseñaron esto lo hicieron en bbdd's separadas quizá fué por escalabilidad, (no digo que sea una buena o mala solución) Si los datos están en BBDD's distintas puedes llevartelas potencialmente a otros servidores.

    No me parece ni una mala ni una buena practica. Con BBDD's diferentes pierdes la posibilidad de tener integridad referencial declarativa, pero el osbrecoste de acceder a otra bbdd no es más uqe el que se corresponde con comprobar la seguridad (que el usuario actual tenga acceso a la BBDD) y eso no es demasiado en absoluto.

     

    En resumen, supongo, que lo hicieron por escalabilidad. Por velocidad o seguridad no tendría sentido, porque en la edición enterprise puedes tener particiones y podrían haber metido cada tabla en un fichero distinto también .

    My two cents.


    Comparte lo que sepas, aprende lo que no sepas (FGG) http://www.portalsql.com
    martes, 5 de julio de 2011 7:52
    Moderador

Todas las respuestas

  • Hola Carlos, en mi experiencia profesional me he topado con algunos casos particulares que no siguen digamoslo el "patron tradicional" en cuanto al diseño y la arquitectura, hay uno en particular que me viene a la mente y es un Sistema de Informacion de una Entidad Bancaria (Core Bancario), en este caso particular debido al alto volumen de transacciones y el esquema de "mercadeo" de la aplicación cada Base de Datos representaba un módulo, asi que podrias tener por ejemplo el siguiente grupo de bases de datos:

    BD_Tesoreria

    BD_Pasivas

    BD_Activas

    BD_Comercio_Exterior

    BD_Clientes

     

    .....

    Y una base de datos con información vinculada a datos de tipo catálogo (monedas, paises, ciudad, etc), por elementos particulares del negocio bancario requerias realizar ciertas operaciones entonces esta separación modular te daba la oportunidad de aplicar ciertas tareas o procesos de forma independiente, con un enfoque mas hacia un producto bancario que al sistema como un todo.

    Cabe destacar que este sistema del cuál te estoy hablando estaba planteada sobre una plataforma un tanto antigua (SQL Server 7.0) y en donde no existian muchos avances y mejoras que actualmente te pueden permitir mitigar ciertos problemas, me vienen a la mente el uso de esquemas y las tablas particionadas. En el caso que planteas por ejemplo la cuarta base de datos (8 tablas frecuentes) perfectamente podria estar contenida en la base de datos operativa(3ra BD), pero con el debido particionamiento, supongo que su separación se debio a la idea de tener un mejor rendimiento sobre tablas de uso intensivo, pero bueno toca "sospecharlo"   :-).

    Espero haber ayudado un poco y bueno cualquier duda estoy a la orden para apoyarte en lo que pueda.

     

    Saludos,

    geek.ms/blogs/ghernandez



    martes, 5 de julio de 2011 0:47
  • Cuando las personas nos ponemos a diseñar, como cuando tomamos cualquier decisión, solemos hacerlo en base a corazonadas, experiencias previas, análisis y buena voluntad.  El único motivo que entiendo que las personas que diseñaron esto lo hicieron en bbdd's separadas quizá fué por escalabilidad, (no digo que sea una buena o mala solución) Si los datos están en BBDD's distintas puedes llevartelas potencialmente a otros servidores.

    No me parece ni una mala ni una buena practica. Con BBDD's diferentes pierdes la posibilidad de tener integridad referencial declarativa, pero el osbrecoste de acceder a otra bbdd no es más uqe el que se corresponde con comprobar la seguridad (que el usuario actual tenga acceso a la BBDD) y eso no es demasiado en absoluto.

     

    En resumen, supongo, que lo hicieron por escalabilidad. Por velocidad o seguridad no tendría sentido, porque en la edición enterprise puedes tener particiones y podrían haber metido cada tabla en un fichero distinto también .

    My two cents.


    Comparte lo que sepas, aprende lo que no sepas (FGG) http://www.portalsql.com
    martes, 5 de julio de 2011 7:52
    Moderador