none
Diseño de una base de datos multiempresa administrativa en sql Server

    Question

  • Mi consulta es como diseñar una base de datos
    para multiempresa, tengo dos opciones:
    -Opcion 1: crear una sola base de datos  con las tablas empresas, menu, usuarios y parametros, tablas de movimientos
    y en cada tabla de movimientos identificar el código de empresa, luego asi puedo
    crear todas las opciones teniendo en cuenta la empresa logueada y si me piden algun
    informe consolidado de empresas se pone un desde- hasta empresa y tengo todo en la misma base
    por ejemplo sacar un libro iva, un stock consolidado de todas las empresas

    -Opcion 2:crear una base de datos de configuracion de empresas, menu, usuarios y parametros
    y una base de datos para cada empresa para movimientos, asi comparten todas, la base de datos
    de configuracion pero cada base de empresa tiene sus propios datos
     aca me surgen dos alternativas, las tablas de usuarios, menu, son para todas
    las empresas iguales entonces las dejo en la base de configuracion pero tengo tablas
    como localidades, provincias, clientes que tambien son para todas las empresas, entonces
    si las pongo en cada empresa repito datos, pero si las dejo en la base de configuracion
    no puedo relacionarla con las tablas de movimientos, o sea no puedo hacer la relacion entre
    tablas de bases de datos distintas


    una duda importante:
    por ejemplo una tabla de condiciones de iva, o de localidades, provincias, etc
    para la opcion 1 existiria una sola de cada una pero para la opcion 2 tengo dos
    alternativas:

    si las pongo en la base de datos de configuracion no podre luego relacionarlas
    con las tablas de movimientos y si las pongo en cada base de datos estaria duplicando
    tablas, una para cada empresa

    Por ejemplo la existencia de articulos se sabe llevar en un campo en la
    tabla de articulos, o el saldo total del cliente en un campo en la tabla
    de clientes, ademas de grabarse los movimientos que dan ese resultado
    pero si estan tablas serian comunes a todas las empresas para la opcion 1 por
    compartir una unica base de datos se podria llevar la existencia de stock
    en una tabla aparte donde se ingrese el id, el idarticulo, el idempresa y la
    existencia, para el caso de clientes tambien crear una tabla de saldos de clientes
    donde se cran el id, el idcleinte, el idempresa, el saldo


    Ambas forman tienen ventajas y desventajas,a mi modo de ver creo que la opcion 1 es
    mas conveniente pero me gustaria escuchar la opinión de ustedes, se que la opcion 1
    me evitaria tener repetido en cada empresa las tablas de configuracion, clientes,
    condicones de iva, proveedores, etc
    La opcion 2 si pongo las tablas estas en la base de configuracion tambien
    evito duplicar datos y tablas pero no puedo hacer la relacion entre tablas
    de distintas bases de datos, o sea por ejemplo de relacionar la tabla de clientes
    con la de movimiento de clientes que estaria en otra base
    Si uso la opcion 2 colocando en cada base de empresa estas tablas teng orepeticion de datos y eso me costaria caro mantenerlo igual en todas las empresas

    Apunto a la mantención de datos por eso quiero ver la forma mas adecuada para el diseño de una base multiempresa administrativa, me parece que la opcion 1 es mas adecuada porque evito repetir tablas para distintas empresas de una misma persona fisica que tiene varias entidades juridicas(empresas), la opcion 2 me preocupa un problema el no poder relacionar la tabla maestra de clientes con la de movimientos de clientes, o sea al no poder relacionar debo controlar bien que se graba en la tabla de movimientos por no tener integridad de datos con la maestra de clientes por el campo clave

    Saludos y gracias


    programador

    Tuesday, May 08, 2012 6:21 PM

Answers

  • Hola.

    Ambas formas son válidas, ambas tienen sus cosas buenas y malas, que nadie mejor que tú va a poder valorar. Quizá la clave sea saber si se puede dar el caso de tener que llevar los datos de una empresa a otro servidor (por el motivo que sea). Si esa posibilidad puede darse, cuanto más independientes sean los datos entre unas empresas y otras, mejor. Si siempre van a convivir, entonces la integridad te facilitará las cosas. La separación también facilita luego el cobro por empresa (si es pertinente).

    Lo ideal sería apostar por una de las vías y definir el procedimiento que permita cambiar de rumbo (juntar si se decide mantener separadas, separar si te decantas por tenerlo todo junto), por si llega un momento en el que las circunstancias así lo requieren.



    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.com
    Sígueme en twitter en http://twitter.com/qwalgrande

    Wednesday, May 09, 2012 8:24 AM
    Moderator