Sistema multi empresa con mysql

[anserkk]

I recommend using one single database for all the companies. You can add one additional column in the tables to identify/differentiate the company the data belongs to. In the long run, this approach will benefit you.

If you keep separate databases for each company, then on a later date if you need to prepare comparison reports then it is going to be cumbersome connecting with different databases. I am not saying that it is not possible to connect to different databases and prepare comparisons. If the count of the number of company's increase in the future this is going to make things much harder for you.

If you keep a separate database for each company, then any change in the structure of the table OR any change in the stored procedures needs to be updated on all the databases. The chances of making mistakes are high and as days go by maintenance becomes a nightmare.

If you go for one single database model then just keep a public variable in your PRG to identify the CompanyID while starting your application, then let each SQL query/update contain this CompanyID

Regards

Anser

[joseluisysturiz]

I recommend using one single database for all the companies. You can add one additional column in the tables to identify/differentiate the company the data belongs to. In the long run, this approach will benefit you.

If you keep separate databases for each company, then on a later date if you need to prepare comparison reports then it is going to be cumbersome connecting with different databases. I am not saying that it is not possible to connect to different databases and prepare comparisons. If the count of the number of company's increase in the future this is going to make things much harder for you.

If you keep a separate database for each company, then any change in the structure of the table OR any change in the stored procedures needs to be updated on all the databases. The chances of making mistakes are high and as days go by maintenance becomes a nightmare.

If you go for one single database model then just keep a public variable in your PRG to identify the CompanyID while starting your application, then let each SQL query/update contain this CompanyID

Regards

Anser

Saludos, el detalle de usar una sola BD es que ...

* voy a teber todos los datos en una sola tabla, eso aumentatria el tanaño de las misnas y el tiempo de respuesta

* tengo que modificar todas las tablas agregando el campo que identifique a que empresa pertenece

* no es bueno tener todos los huevos en una misma cesta (metáfora)

* tengo que modificar todas las consultas y reportes con WHERE para saber a queempresa pertenece

* cuando haga respaldo como debe ser por empresa debo modificar el sistema de respaldo para que solo seleccione los registros de la empresa que respaldo

* otros

Todo eso lo evito usando una BD por empresa, solo debo al seleccionar la empresa cambiar la conexión a esa BD y listo. .sin ningun cambio en códigos...

Se pueden tener varias conexiones simultáneas
Sin problemas y sería solo para los recortes de consolidación que serían pocos

es mi punto y análisis que hice..igual gracias por tu sugerencia...Saludos...

[nnicanor]

Por experiencia, crear un solo modelo de datos multiempresa es mucho mas eficiente, en SQL no importa el numero de registro, lo importante es lo optimizados que se creen los indices para manipular la informacion, en nuestra empresa hemos utilizado esquema multiempresa con millones de registros y nos ha funcionado perfecto, las comparaciones van al vuelo.

Saludos