Sistema multiempresa

Hola, me imagino que hablaras de usar Stores no? ahora bien, cuando ingresas
una nueva empresa vas a tener que cambiar el Store verdad? al igual que si
una se borra por alguna razon.

Esto de andar reescribiendo los SP a mi mucho no me gusta, porque tu
aplicacion empieza a ser dificil a los cambios :(

"Ricardo Passians" escribió en el mensaje
news:

> Vuelvo a repetir, esta es solo mi opinion :-)
>

Claro. Se respeta la opinión.. Yo por el contrario soy partidario de la
separación pues muchos de los controles de consolidación y similares

pueden

hacerse desde la aplicación.

No.. No tengo que modificar los SP's. Tengo un script para crear la base de
datos de una nueva empresa que también crea los SP's (iguales en cada BD) y
estos son locales a cada BD. Cada base de datos se crea con un nombre
correspondiente al código de cada empresa de modo que la aplicación las
pueda diferenciar. Estoy hablando de aplicaciones terminadas cuyos SP's no
se estan modificando frecuentemente.

Para consolidar, por ejemplo, recorro las bases de datos ("las empresas") y
ejecuto el SP requerido (o el query segun sea el caso) en cada base de
datos. El conjunto resultante en cada iteración lo voy acumulando en un
repositorio local de la aplicacion (A saber: Uso Visual Foxpro que facilita
mucho esto con sus tablas locales temporales que también se llaman
"cursores" aunque no tienen nada que ver con las de SQLSvr).

El proceso de consolidar podrá ser más lento de lo normal que tener todo en
la misma BD... ok pero... los usuarios no consolidan a diario y además saben
que el proceso ha de ser más lento que lo normal. En la práctica no les
preocupa mucho.

Ahora bien, que si decido agregar o modificar un SP pues tengo que
modificarlo en cada BD. ahi te doy la razon de que es mas dificil pero
es cuestion de automatizarlo para que sea mas simple este proceso.

Sin embargo, como dice la joven arriba, tener todo en una sola base de datos
implicaria practicamente en todo WHERE incluir la empresa como filtro lo
cual produce mayor probabilidad de errores de programacion (como mostrar
resumenes erroneos) y ademas haya que tener muy probablemente mayor
cantidad de indices para incluir la empresa. Es como sumar una dimensión
al espacio:).


Ricardo Passians

"Maximiliano D. A." wrote in message
news:

Hola, me imagino que hablaras de usar Stores no? ahora bien, cuando

ingresas

una nueva empresa vas a tener que cambiar el Store verdad? al igual que si
una se borra por alguna razon.

Esto de andar reescribiendo los SP a mi mucho no me gusta, porque tu
aplicacion empieza a ser dificil a los cambios :(

"Ricardo Passians" escribió en el mensaje
news:
> > Vuelvo a repetir, esta es solo mi opinion :-)
> >
>
> Claro. Se respeta la opinión.. Yo por el contrario soy partidario de la
> separación pues muchos de los controles de consolidación y similares
pueden
> hacerse desde la aplicación.
>
>
>

Puedes hacer eso de los sps sin tanta complicación de dos formas:

1.- Los creas en la BBDD model, cuando ejecutes create database ya estarán
(los sps y todas las tablas que tengas).
2.- llamandolos con sp_ y poniendolos en master, además de marcarlos como
objetos del sistema. Se ejecutan en el entorno de la BBDD en que estés, pero
solo los tienes una vez, lo que hace más fácil su administracio´n.

sobre la discusión de si multiempresa en multiples BBDDS o no hay mil
razones a favor y en contra así que cada cual que haga como le guste.
En algunos casos por ejemplo una inyección de código podría mostrar datos de
otras empresas... y no nos olvidemos que todos los programas tienen
agujeros...


-
Miguel Egea Gómez
Microsoft SQL-Server MVP
Webmaster de PortalSql.Com
¿Te interesa participar en las reuniones
del grupo de Usuarios de SQL-Server y .NET
Se harán en levante de España, (Alicante o Murcia)?



"Ricardo Passians" escribió en el mensaje
news:

No.. No tengo que modificar los SP's. Tengo un script para crear la base
de
datos de una nueva empresa que también crea los SP's (iguales en cada BD)
y
estos son locales a cada BD. Cada base de datos se crea con un nombre
correspondiente al código de cada empresa de modo que la aplicación las
pueda diferenciar. Estoy hablando de aplicaciones terminadas cuyos SP's
no
se estan modificando frecuentemente.

Para consolidar, por ejemplo, recorro las bases de datos ("las empresas")
y
ejecuto el SP requerido (o el query segun sea el caso) en cada base de
datos. El conjunto resultante en cada iteración lo voy acumulando en un
repositorio local de la aplicacion (A saber: Uso Visual Foxpro que
facilita
mucho esto con sus tablas locales temporales que también se llaman
"cursores" aunque no tienen nada que ver con las de SQLSvr).

El proceso de consolidar podrá ser más lento de lo normal que tener todo
en
la misma BD... ok pero... los usuarios no consolidan a diario y además
saben
que el proceso ha de ser más lento que lo normal. En la práctica no les
preocupa mucho.

Ahora bien, que si decido agregar o modificar un SP pues tengo que
modificarlo en cada BD. ahi te doy la razon de que es mas dificil
pero
es cuestion de automatizarlo para que sea mas simple este proceso.

Sin embargo, como dice la joven arriba, tener todo en una sola base de
datos
implicaria practicamente en todo WHERE incluir la empresa como filtro lo
cual produce mayor probabilidad de errores de programacion (como mostrar
resumenes erroneos) y ademas haya que tener muy probablemente mayor
cantidad de indices para incluir la empresa. Es como sumar una dimensión
al espacio:).


Ricardo Passians

"Maximiliano D. A." wrote in message
news:

Hola, me imagino que hablaras de usar Stores no? ahora bien, cuando

ingresas

una nueva empresa vas a tener que cambiar el Store verdad? al igual que
si
una se borra por alguna razon.

Esto de andar reescribiendo los SP a mi mucho no me gusta, porque tu
aplicacion empieza a ser dificil a los cambios :(

"Ricardo Passians" escribió en el mensaje
news:
> > Vuelvo a repetir, esta es solo mi opinion :-)
> >
>
> Claro. Se respeta la opinión.. Yo por el contrario soy partidario de
> la
> separación pues muchos de los controles de consolidación y similares
pueden
> hacerse desde la aplicación.
>
>
>

Puedes hacer eso de los sps sin tanta complicación de dos formas:

1.- Los creas en la BBDD model, cuando ejecutes create database ya estarán
(los sps y todas las tablas que tengas).
2.- llamandolos con sp_ y poniendolos en master, además de marcarlos como
objetos del sistema. Se ejecutan en el entorno de la BBDD en que estés,

pero

solo los tienes una vez, lo que hace más fácil su administracio´n.

Gracias ... muy buena opción.

sobre la discusión de si multiempresa en multiples BBDDS o no hay mil
razones a favor y en contra así que cada cual que haga como le guste.
En algunos casos por ejemplo una inyección de código podría mostrar datos

de

otras empresas... y no nos olvidemos que todos los programas tienen
agujeros...

Claro. La seguridad nunca será totalmente inviolable aún teniendo "todo
junto y centralizado". Depende mucho del caso particular sin embargo.

Miguel,

¿Cómo marcas un procedimiento almacenado como de sistema ?

Eso no está documentado. ¿Verdad?

Un abrazo

Jesús
MVP