Re: Sistema multiempresa

A ver, vos me decis que por cada BDD armas los SP necesarios y ademas

tenes

uno que consolida que recorre las BDD (como?) y que todo esto es mejor que
poner todo junto?

Mala interpretacion. No tengo un SP de consolidación. Hago el proceso
desde mi aplicación (el front-end) que es unir los resultados devueltos por
la llamada a los sp's de cada BD. Los SP's trabajan sobre la propia BD en
que residen. El recorrido no lo hago en un SP, lo hago desde mi aplicación,
en ésta también se programa no ? :)

A ver, no se cual es tu experiencia, pero yo suelo ser una persona que me
gusta ver lo que hacen las grandes empresas y ver que puedo copiar y que
cosa no :-p


Una de las cosas que aprendi en todo estos años, es que los ERP mas

grandes

del planeta (conozco una instalacion SAP que superar los 5TB) tienen todo

en

una sola BDD (el multiempresa) y nunca dividen en varias BDD.

No lo discuto, esos ERPs son super aplicaciones con años de depuración y
gran cantidad de personal de control de calidad. Pero para los que tenemos
pequeñas empresas y no más de 5 programadores, sólo digo que la programación
tiende a ser más compleja y propensa a errores por el simple hecho de tener
que filtrar cada query con la columna "empresa". Y si aparte de empresa,
ya tenemos una variable como "Division" o "Centro de Costo", solo hay que
imaginarse:)

Esto basicamente por todo lo que comente antes y que vos bien dijistes,
debes cambiar el SP de consolidacion y ademas tenes otros problemas como

por

ej:

Error.. No hay un SP de consolidacion, como digo arriba. Consolido los
resultados en la aplicación.

La integridad Referencial.

Esta ultima la debes armar con Trigger y no vas a poder usar FK.

Claro que sí porque la integridad referencial es dentro de las tablas de
cada BD. Ahora bien, si es que hablas de tablas comunes a varias
empresas, bueno ya eso es otra cosa pero, puedes tenerlas en la base de
datos del sistema que seria otra o en su defecto copiar los datos a medida
que se modifiquen. Normalmente las tablas que se hacen comunes no son tablas
de operaciones, sino tablas maestras como de clientes, articulos, etc..
Pero para tu caso, teniendo todo junto, me imagino que sería más complicado
hacer cada vez una excepción de no filtrar la empresa cuando se trate de una
tabla comun.

Ahora bien, esto de dividir las cosas es una idea y practica de muchos
developer (sobre todo Fox) porque hay una cosa que es cierta:

Fox - Access o cualquier bdd de este tipo trabajn muy pero muy distinto a
SQL - Oracle u DB2 por ej.

Es claro.. Eso no se discute. Hablé de una manipulación local en Visual
Foxpro de datos devueltos desde el servidor SQL. Esta manipulación aunque
afecta el desempeño final para el usuario, no afecta el rendimiento del
servidor que interfiera con los demás usuarios.

Entonces se aplican las viejas tecnicas en un motor como SQL, cuando poner
una columna es algo muy simple de verdad y no se complica ninguna consulta
te lo aseguro.

Bueno, cuestion de opinion para mi tener que agregar un AND en cada WHERE y
cada JOIN para incluir la empresa me parece complicado y aumenta la
posibilidad de errores, aunque entiendo que pueda ser lo ideal tenerlo así.

Mira, el ERP que tenemos en la empresa tambien esta armado asi y no es

SAP,

y tenemos mas de 10 empresas dentro y te digo que es algo simple y no hay
ningun tipo de confusion :-)


Vuelvo a repetir, no veo ningun beneficio en dividir las empresas en mas

de

una BDD!!

Bueno, amigo, aunque lo digas como si fuera una sentencia, la tuya es
también una opinión subjetiva, igual que la mia. La respeto pero no la
comparto.

podrias exponer vos que ventajas le ves a ese modelo? porque yo ya
expuse las desventajas y las ventajas del otro modelo :-)

La ventaja para mi es que programo la aplicación simplemente ignorando el
parámetro "empresa", desarrollando así consultas, búsquedas, combinaciones,
sp's, más sencillos que permitan mejor RAD y menos posibilidad de cometer
errores. Eso para mi es más que suficiente ventaja. Otra ventaja sería
excluir la necesidad de índices sobre la columna "empresa" sobre todo en
tablas de muchos registros, peor aún si ya existe otra variable como
"division" o "centro de costo".