Re: Sistema multiempresa

Hola, parece que esta interesante el tema :-), hay un temita: va a ser
dificil convencer a un developer Fox :-p (broma)

Vos tenes sus SP correspondientes por BDD, luego consolidas sergun vos de
esta forma:

Llamo a todos los SP de cada BDD me traigo todo lo que dicen esos SP al
cliente y ahi consolido, es verdad esto?

Aca estas duplicando la informacion, (en el cliente claro ;-). O sea, estas
sobrecargando al cliente (no es un cliente ligero como bien se dice) ya que
mucho de los procesos los estas haciendo de forma local, por mas que este
proceso se haga una vez cada 30 dias.

Es verdad que no todo son SP en la vida, pero son una herramienta donde hace
que los procesos dentro de Sql-server funcionen de forma muy eficiente,
segura y se pueda reutilizar.

Me gustaria hacerte por ejemplo una pregunta veamos:

Vos tenes X BDD por empresa, bien, luego de tener el sistema funcionando
tenes que hacerle una modificacion a una tabla que esta en todas las BDD
(supongamos agregar un campo nuevo), bien, vas a un cliente y tiene 100 BDD
porque maneja 100 empresas, esta tabla estan en las 100 BDD y ademas tenes
todos los SP correspondientes no?

Al suceder esto, es simple el upgrate?

Yo los sistemas multiempresa los armo en una BDD solamente no porque los ERP
tambien lo hagan asi, sino que en mi experiencia es la mejor forma de
hacerlo, y ademas cuando desarrollo mis sistemas en los casos de uso y
requerimientos ya expongo que sera multiempresa.

Otra cosa que no me gustaria dejarle al cliente la posibilidad de andar
creando,borrando BDD en mi servidor, esa es una tarea de los DBA ;-), tu
aplicacion cada vez que quiera un usuario crear una nueva empresa lo que
esta haciendo es crear BDD en el servidor con todos los problemas que ello
puede ocasionar!! pero si ves al servidor como un solo repositorio donde
estara solo tu aplicacion entonces tu punto de vista y arquitectura es mas
valido, pero si vas a instalar la aplicacion en un cliente donde te de un
servidor y exista un Dba del mismo, no creo que le guste mucho que se anden
creando BDD sin su control o autorizacion :-)



Salu2
Maxi
Buenos Aires - Argentina
Desarrollador Microsoft 3 Estrellas .NET
Nunca consideres el estudio como una obligación sino como
una oportunidad para penetrar en el bello y maravillosos
mundo del saber.
- Albert Einstein



"Ricardo Passians" escribió en el mensaje
news:

>
> Aja, bien o sea accedes a las tablas de tu sistema de forma directa, con
el
> inicio de sesion verdad. Como haces para que un usuario (sesion) no

acceda

a
> esas mismas tablas desde un Excel? Ademas si no usas un SP y estas

pasando

> la informacion al cliente estas saturando enormemente la RED con datos
> totalmente redundantes.
>

Sobre lo de excel no entendí.
Pero por lo de sp y saturación estás totalmente equivocado. Cuáles datos
redundantes ? Piensas que hago DW ? Parece como si estuviéramos hablando

de

cosas diferentes. Estoy hablando de consolidar resultados obtenidos
independientemente de cada BD/empresa. Ok... es algo mas lento que

tenerlo

todo junto, lo digo arriba. Pero no es algo de vida o muerte pues los
usuarios NO CONSOLIDAN a diario. Ademas cuando tiran un reporte No
consolidado los resultados del SP de la BD circulan al cliente... cual es
el problema que para consolidar se repita este proceso para cada BD?

Aclaro de nuevo. No es que no uso SP's.. Es que no uso uno para

CONSOLIDAR.

Pero cada BD tiene sus SP's para extraer los datos y devolvermelos al

front

end y los combino (o los UNO, mejor dicho) ya en la aplicación en tablas
temporales locales, las cuales maneja VFP mejor que cualquier lenguaje.

Pero

estos cursores (tablas temporales) de visual foxpro NO TIENEN NADA QUE VER
con los cursores de SQL Server ni con los de ADO.NET, cursores que parecen
ser tu fijación y creo que es de donde viene la malinterpretación.
Si te interesa aclarar mejor la confusión investiga por ahí sobre las

tablas

temporales locales de VFP.

Viejo, no todo es SP's en la vida... :)))

> >
> > 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:)
> >
>
> Tu sistemas hoy puede ser pequeño pero mañana enorme, no puedes copiar
todo
> lo que hacen los grandes, pero si vas a trabajar con SQL-Server te

aseguro

> que estas tecnicas las tiene un sistemita pequeño tambien!! ahora si
> trabajas con Fox o Access la historia es otra.
>
>
> > Error.. No hay un SP de consolidacion, como digo arriba. Consolido los
> > resultados en la aplicación.
>
> Vuelvo a repetir, pasas todos los datos de un lado al otro (saturando
> enormemente la RED).
>

Estas muy equivocado insisto. Recuerda que estoy hablando de un caso real

y

comprobado. Si fuese como dices ya los usuarios hubiesen gritado y para el
caso que me ocupa no es que sean tantos pero son cerca de 100. Lo que

pasa

es que Visual Foxpro nos da la ventaja de tener tablas locales temporales
(en el cliente) donde hacer cosas con los resultados que nos devuelve SQL
Server y complementan eficientemente situaciones como esta. Lo sé... es
que con otros lenguajes no se puede. Comprendo tu sorpresa..:))) Los de
VFP no los llames cursores para que no te confundas, digamosles tablas
temporales.

En sintesis, la carga agregada de tener que unir los datos en el cliente

no

es relevante para un proceso eventual como una consolidación.


>
> Sabes que en ADO.NET 2.0 no existen mas los cursores? te imaginas

porque?

> justamente para que los developer no hagan tu tecnica que es para nada
> recomendada. Porque tener las cosas duplicadas si ya estan en un
> repositorio?
> Porque saturar la RED?
>
>
> >
> > 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.
>
> Si la de las mismas BDD ok pero las tablas compartidas no, por lo cual o
> debes aplicar TR con los problemas de mantenimiento que lleva no. En

sql2k

> la forma natural de hacer Integridad referencial es por medio de Claves
> Externas y no por TR
>
> > 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.
>
> Seguro que no afecta el servidor? pone un contador de transferencias de
RED
> y contame ;-). Lo afecta porque estas haciendo pasar los datos completos
de
> un lado al otro por tu RED y seguramente si estas haciendo muchos SELECT

*

> FROM el servidor esta haciendo Table Scan y esto afecta enormemente el
> rendimiento del servidor.
>


Lo afecta.. Pero no tanto como crees. Yo estoy seguro que muchos, no

digo

que tu caso, de los que tienen todo junto en una BD multiempresa no se han
detenido a probar la otra forma simplemente porque los ERP's lo usan así.


Saludos, amigo.

Ricardo Passians

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.778 / Virus Database: 525 - Release Date: 15/10/2004

Hola, parece que esta interesante el tema :-), hay un temita: va a ser
dificil convencer a un developer Fox :-p (broma)

Me lo han dicho antes. X-DDDD

Vos tenes sus SP correspondientes por BDD, luego consolidas sergun vos de
esta forma:

Llamo a todos los SP de cada BDD me traigo todo lo que dicen esos SP al
cliente y ahi consolido, es verdad esto?

Aca estas duplicando la informacion, (en el cliente claro ;-). O sea,

estas

sobrecargando al cliente (no es un cliente ligero como bien se dice) ya

que

mucho de los procesos los estas haciendo de forma local, por mas que este
proceso se haga una vez cada 30 dias.

Sí. No lo estoy negando.

Es verdad que no todo son SP en la vida, pero son una herramienta donde

hace

que los procesos dentro de Sql-server funcionen de forma muy eficiente,
segura y se pueda reutilizar.

Muy de acuerdo. Yo de hecho lleno las BD's de SP's, de funciones de usuario
aunque muchos no las usen, utilizo indices clustered, me auxilio del index
tunning, de las estadísticas, hago vistas indexadas, minimizo el uso de
triggers, no uso cursores de SQL, normalizo y desnormalizo racionalmente, y
en general trato de aprovechar el servidor para procurar un desempeño
eficiente.
Pero eso de la consolidacion lo hago del lado del cliente pues me ha
resultado mas practico por las razones expuestas en otros mensajes. y
aprovecho las ventajas que me dan las tablas locales de Visual Foxpro para
ello.

Me gustaria hacerte por ejemplo una pregunta veamos:

Vos tenes X BDD por empresa, bien, luego de tener el sistema funcionando
tenes que hacerle una modificacion a una tabla que esta en todas las BDD
(supongamos agregar un campo nuevo), bien, vas a un cliente y tiene 100

BDD

porque maneja 100 empresas, esta tabla estan en las 100 BDD y ademas tenes
todos los SP correspondientes no?

Al suceder esto, es simple el upgrate?

No es simple pero es... automatizable. Además es raro (muy raro) al menos
en mi experiencia tener tantas empresas para un mismo sistema. Sólo imagina
que yo cobro por cantidad de empresas :))))) A lo sumo dos o tres o cuatro
máximo es lo que acostumbro a ver en el mercado de las empresas medianas y
pequeñas que es donde me desenvuelvo. La gran mayoría de los clientes solo
manejan una empresa.

Yo los sistemas multiempresa los armo en una BDD solamente no porque los

ERP

tambien lo hagan asi, sino que en mi experiencia es la mejor forma de
hacerlo, y ademas cuando desarrollo mis sistemas en los casos de uso y
requerimientos ya expongo que sera multiempresa.

Otra cosa que no me gustaria dejarle al cliente la posibilidad de andar
creando,borrando BDD en mi servidor, esa es una tarea de los DBA ;-), tu
aplicacion cada vez que quiera un usuario crear una nueva empresa lo que
esta haciendo es crear BDD en el servidor con todos los problemas que ello
puede ocasionar!!

Nooooooo... claro que no. Las empresas no se crean "on the fly". Se
establecen en la negociación de venta regularmente. De hecho es poco
probable aumentar la cantidad de empresas luego que se estableció desde el
principio. Y cuando ha ocurrido eso lo configuramos nosotros mismos como
una nueva negociación y autorizados por el DBA, si este existe, porque no
siempre existe uno.. No es que eso se deja a un usuario de la aplicacion
crear arbitrariamente empresas... claro que no, el riesgo es mucho y
además,, repito, cobramos por cantidad de empresas :)).

Bien, ahora entiendo tu caso de porque las empresas las controlas asi :-),
no hay mas nada por discutir entonces, en tu escenario esa solucion puede
ser interesante, lastima el gran mantenimiento que te lleva si tenes que
cambiar algo, porque lo debes replicar en cada BDD, pero como cobras por BDD
se entiende el negocio :-)

Bue, entonces me alegro que te esten funcionando bien las cosas y que aun
puedas poder venderle a un cliente un sistema por empresa, pense que ese
tipo de cosas ya estaban fuera.

De todas formas creo que hemos hecho un interesante debate de una forma bien
profesional y con 2 puntos de vista totalmente opuestos, esto le dara valor
al grupo ya que cada cual podra sacar sus propias conclusiones al respecto
:-)

Un abrazo y espero poder verte seguido por aqui, para charlar de lo que nos
gusta :-)




Maxi

Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)
Mail: Maxi_accotto[arroba]speedy.com.ar

Msn Messager:

"Ricardo Passians" escribió en el mensaje
news:%

Hola, parece que esta interesante el tema :-), hay un temita: va a ser
dificil convencer a un developer Fox :-p (broma)

Me lo han dicho antes. X-DDDD

Vos tenes sus SP correspondientes por BDD, luego consolidas sergun vos de
esta forma:

Llamo a todos los SP de cada BDD me traigo todo lo que dicen esos SP al
cliente y ahi consolido, es verdad esto?

Aca estas duplicando la informacion, (en el cliente claro ;-). O sea,

estas

sobrecargando al cliente (no es un cliente ligero como bien se dice) ya

que

mucho de los procesos los estas haciendo de forma local, por mas que este
proceso se haga una vez cada 30 dias.

Sí. No lo estoy negando.

Es verdad que no todo son SP en la vida, pero son una herramienta donde

hace

que los procesos dentro de Sql-server funcionen de forma muy eficiente,
segura y se pueda reutilizar.

Muy de acuerdo. Yo de hecho lleno las BD's de SP's, de funciones de
usuario
aunque muchos no las usen, utilizo indices clustered, me auxilio del
index
tunning, de las estadísticas, hago vistas indexadas, minimizo el uso de
triggers, no uso cursores de SQL, normalizo y desnormalizo racionalmente,
y
en general trato de aprovechar el servidor para procurar un desempeño
eficiente.
Pero eso de la consolidacion lo hago del lado del cliente pues me ha
resultado mas practico por las razones expuestas en otros mensajes. y
aprovecho las ventajas que me dan las tablas locales de Visual Foxpro para
ello.

Me gustaria hacerte por ejemplo una pregunta veamos:

Vos tenes X BDD por empresa, bien, luego de tener el sistema funcionando
tenes que hacerle una modificacion a una tabla que esta en todas las BDD
(supongamos agregar un campo nuevo), bien, vas a un cliente y tiene 100

BDD

porque maneja 100 empresas, esta tabla estan en las 100 BDD y ademas
tenes
todos los SP correspondientes no?

Al suceder esto, es simple el upgrate?

No es simple pero es... automatizable. Además es raro (muy raro) al
menos
en mi experiencia tener tantas empresas para un mismo sistema. Sólo
imagina
que yo cobro por cantidad de empresas :))))) A lo sumo dos o tres o cuatro
máximo es lo que acostumbro a ver en el mercado de las empresas medianas y
pequeñas que es donde me desenvuelvo. La gran mayoría de los clientes
solo
manejan una empresa.

Yo los sistemas multiempresa los armo en una BDD solamente no porque los

ERP

tambien lo hagan asi, sino que en mi experiencia es la mejor forma de
hacerlo, y ademas cuando desarrollo mis sistemas en los casos de uso y
requerimientos ya expongo que sera multiempresa.

Otra cosa que no me gustaria dejarle al cliente la posibilidad de andar
creando,borrando BDD en mi servidor, esa es una tarea de los DBA ;-), tu
aplicacion cada vez que quiera un usuario crear una nueva empresa lo que
esta haciendo es crear BDD en el servidor con todos los problemas que
ello
puede ocasionar!!

Nooooooo... claro que no. Las empresas no se crean "on the fly". Se
establecen en la negociación de venta regularmente. De hecho es poco
probable aumentar la cantidad de empresas luego que se estableció desde el
principio. Y cuando ha ocurrido eso lo configuramos nosotros mismos como
una nueva negociación y autorizados por el DBA, si este existe, porque no
siempre existe uno.. No es que eso se deja a un usuario de la aplicacion
crear arbitrariamente empresas... claro que no, el riesgo es mucho y
además,, repito, cobramos por cantidad de empresas :)).

Yo pienso que eso si Ricardo cobra por empresas instaladas, el tenerlas en
BD separadas o tenerlas en una sola es algo que al cliente no le afecta o
sea este no le importaria la implementacion interna que tenga.



"MAXI" wrote in message
news:

Bien, ahora entiendo tu caso de porque las empresas las controlas asi :-),
no hay mas nada por discutir entonces, en tu escenario esa solucion puede
ser interesante, lastima el gran mantenimiento que te lleva si tenes que
cambiar algo, porque lo debes replicar en cada BDD, pero como cobras por

BDD

se entiende el negocio :-)

Bue, entonces me alegro que te esten funcionando bien las cosas y que aun
puedas poder venderle a un cliente un sistema por empresa, pense que ese
tipo de cosas ya estaban fuera.

De todas formas creo que hemos hecho un interesante debate de una forma

bien

profesional y con 2 puntos de vista totalmente opuestos, esto le dara

valor

al grupo ya que cada cual podra sacar sus propias conclusiones al respecto
:-)

Un abrazo y espero poder verte seguido por aqui, para charlar de lo que

nos

gusta :-)




Maxi

Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)
Mail: Maxi_accotto[arroba]speedy.com.ar

Msn Messager:

"Ricardo Passians" escribió en el mensaje
news:%
>> Hola, parece que esta interesante el tema :-), hay un temita: va a ser
>> dificil convencer a un developer Fox :-p (broma)
>>
>
> Me lo han dicho antes. X-DDDD
>
>> Vos tenes sus SP correspondientes por BDD, luego consolidas sergun vos

de

>> esta forma:
>>
>> Llamo a todos los SP de cada BDD me traigo todo lo que dicen esos SP al
>> cliente y ahi consolido, es verdad esto?
>>
>> Aca estas duplicando la informacion, (en el cliente claro ;-). O sea,
> estas
>> sobrecargando al cliente (no es un cliente ligero como bien se dice) ya
> que
>> mucho de los procesos los estas haciendo de forma local, por mas que

este

>> proceso se haga una vez cada 30 dias.
>>
>
> Sí. No lo estoy negando.
>
>> Es verdad que no todo son SP en la vida, pero son una herramienta donde
> hace
>> que los procesos dentro de Sql-server funcionen de forma muy eficiente,
>> segura y se pueda reutilizar.
>>
>
> Muy de acuerdo. Yo de hecho lleno las BD's de SP's, de funciones de
> usuario
> aunque muchos no las usen, utilizo indices clustered, me auxilio del
> index
> tunning, de las estadísticas, hago vistas indexadas, minimizo el uso de
> triggers, no uso cursores de SQL, normalizo y desnormalizo

racionalmente,

> y
> en general trato de aprovechar el servidor para procurar un desempeño
> eficiente.
> Pero eso de la consolidacion lo hago del lado del cliente pues me ha
> resultado mas practico por las razones expuestas en otros mensajes. y
> aprovecho las ventajas que me dan las tablas locales de Visual Foxpro

para

> ello.
>
>
>> Me gustaria hacerte por ejemplo una pregunta veamos:
>>
>> Vos tenes X BDD por empresa, bien, luego de tener el sistema

funcionando

>> tenes que hacerle una modificacion a una tabla que esta en todas las

BDD

>> (supongamos agregar un campo nuevo), bien, vas a un cliente y tiene 100
> BDD
>> porque maneja 100 empresas, esta tabla estan en las 100 BDD y ademas
>> tenes
>> todos los SP correspondientes no?
>>
>> Al suceder esto, es simple el upgrate?
>>
>
> No es simple pero es... automatizable. Además es raro (muy raro) al
> menos
> en mi experiencia tener tantas empresas para un mismo sistema. Sólo
> imagina
> que yo cobro por cantidad de empresas :))))) A lo sumo dos o tres o

cuatro

> máximo es lo que acostumbro a ver en el mercado de las empresas medianas

y

> pequeñas que es donde me desenvuelvo. La gran mayoría de los clientes
> solo
> manejan una empresa.
>
>
>> Yo los sistemas multiempresa los armo en una BDD solamente no porque

los

> ERP
>> tambien lo hagan asi, sino que en mi experiencia es la mejor forma de
>> hacerlo, y ademas cuando desarrollo mis sistemas en los casos de uso y
>> requerimientos ya expongo que sera multiempresa.
>>
>> Otra cosa que no me gustaria dejarle al cliente la posibilidad de andar
>> creando,borrando BDD en mi servidor, esa es una tarea de los DBA ;-),

tu

>> aplicacion cada vez que quiera un usuario crear una nueva empresa lo

que

>> esta haciendo es crear BDD en el servidor con todos los problemas que
>> ello
>> puede ocasionar!!
>
> Nooooooo... claro que no. Las empresas no se crean "on the fly". Se
> establecen en la negociación de venta regularmente. De hecho es poco
> probable aumentar la cantidad de empresas luego que se estableció desde

el

> principio. Y cuando ha ocurrido eso lo configuramos nosotros mismos

como

> una nueva negociación y autorizados por el DBA, si este existe, porque

no

> siempre existe uno.. No es que eso se deja a un usuario de la

aplicacion

> crear arbitrariamente empresas... claro que no, el riesgo es mucho y
> además,, repito, cobramos por cantidad de empresas :)).
>
>
>
>

Ciertamente.


"Berta Gomez" wrote in message
news:

Yo pienso que eso si Ricardo cobra por empresas instaladas, el tenerlas en
BD separadas o tenerlas en una sola es algo que al cliente no le afecta o
sea este no le importaria la implementacion interna que tenga.



"MAXI" wrote in message
news:
> Bien, ahora entiendo tu caso de porque las empresas las controlas asi

:-),

> no hay mas nada por discutir entonces, en tu escenario esa solucion

puede

> ser interesante, lastima el gran mantenimiento que te lleva si tenes que
> cambiar algo, porque lo debes replicar en cada BDD, pero como cobras por
BDD
> se entiende el negocio :-)
>
> Bue, entonces me alegro que te esten funcionando bien las cosas y que

aun

> puedas poder venderle a un cliente un sistema por empresa, pense que ese
> tipo de cosas ya estaban fuera.
>
> De todas formas creo que hemos hecho un interesante debate de una forma
bien
> profesional y con 2 puntos de vista totalmente opuestos, esto le dara
valor
> al grupo ya que cada cual podra sacar sus propias conclusiones al

respecto

> :-)
>
> Un abrazo y espero poder verte seguido por aqui, para charlar de lo que
nos
> gusta :-)
>
>
>
>
> Maxi
>
> Buenos Aires - Argentina
> Desarrollador .NET 3 Estrellas
> Microsoft User Group (MUG)
> Mail: Maxi_accotto[arroba]speedy.com.ar
>
> Msn Messager:
>
> "Ricardo Passians" escribió en el mensaje
> news:%
> >> Hola, parece que esta interesante el tema :-), hay un temita: va a

ser

> >> dificil convencer a un developer Fox :-p (broma)
> >>
> >
> > Me lo han dicho antes. X-DDDD
> >
> >> Vos tenes sus SP correspondientes por BDD, luego consolidas sergun

vos

de
> >> esta forma:
> >>
> >> Llamo a todos los SP de cada BDD me traigo todo lo que dicen esos SP

al

> >> cliente y ahi consolido, es verdad esto?
> >>
> >> Aca estas duplicando la informacion, (en el cliente claro ;-). O sea,
> > estas
> >> sobrecargando al cliente (no es un cliente ligero como bien se dice)

ya

> > que
> >> mucho de los procesos los estas haciendo de forma local, por mas que
este
> >> proceso se haga una vez cada 30 dias.
> >>
> >
> > Sí. No lo estoy negando.
> >
> >> Es verdad que no todo son SP en la vida, pero son una herramienta

donde

> > hace
> >> que los procesos dentro de Sql-server funcionen de forma muy

eficiente,

> >> segura y se pueda reutilizar.
> >>
> >
> > Muy de acuerdo. Yo de hecho lleno las BD's de SP's, de funciones de
> > usuario
> > aunque muchos no las usen, utilizo indices clustered, me auxilio del
> > index
> > tunning, de las estadísticas, hago vistas indexadas, minimizo el uso

de

> > triggers, no uso cursores de SQL, normalizo y desnormalizo
racionalmente,
> > y
> > en general trato de aprovechar el servidor para procurar un desempeño
> > eficiente.
> > Pero eso de la consolidacion lo hago del lado del cliente pues me ha
> > resultado mas practico por las razones expuestas en otros mensajes. y
> > aprovecho las ventajas que me dan las tablas locales de Visual Foxpro
para
> > ello.
> >
> >
> >> Me gustaria hacerte por ejemplo una pregunta veamos:
> >>
> >> Vos tenes X BDD por empresa, bien, luego de tener el sistema
funcionando
> >> tenes que hacerle una modificacion a una tabla que esta en todas las
BDD
> >> (supongamos agregar un campo nuevo), bien, vas a un cliente y tiene

100

> > BDD
> >> porque maneja 100 empresas, esta tabla estan en las 100 BDD y ademas
> >> tenes
> >> todos los SP correspondientes no?
> >>
> >> Al suceder esto, es simple el upgrate?
> >>
> >
> > No es simple pero es... automatizable. Además es raro (muy raro) al
> > menos
> > en mi experiencia tener tantas empresas para un mismo sistema. Sólo
> > imagina
> > que yo cobro por cantidad de empresas :))))) A lo sumo dos o tres o
cuatro
> > máximo es lo que acostumbro a ver en el mercado de las empresas

medianas

y
> > pequeñas que es donde me desenvuelvo. La gran mayoría de los clientes
> > solo
> > manejan una empresa.
> >
> >
> >> Yo los sistemas multiempresa los armo en una BDD solamente no porque
los
> > ERP
> >> tambien lo hagan asi, sino que en mi experiencia es la mejor forma de
> >> hacerlo, y ademas cuando desarrollo mis sistemas en los casos de uso

y

> >> requerimientos ya expongo que sera multiempresa.
> >>
> >> Otra cosa que no me gustaria dejarle al cliente la posibilidad de

andar

> >> creando,borrando BDD en mi servidor, esa es una tarea de los DBA ;-),
tu
> >> aplicacion cada vez que quiera un usuario crear una nueva empresa lo
que
> >> esta haciendo es crear BDD en el servidor con todos los problemas que
> >> ello
> >> puede ocasionar!!
> >
> > Nooooooo... claro que no. Las empresas no se crean "on the fly".

Se

> > establecen en la negociación de venta regularmente. De hecho es poco
> > probable aumentar la cantidad de empresas luego que se estableció

desde

el
> > principio. Y cuando ha ocurrido eso lo configuramos nosotros mismos
como
> > una nueva negociación y autorizados por el DBA, si este existe, porque
no
> > siempre existe uno.. No es que eso se deja a un usuario de la
aplicacion
> > crear arbitrariamente empresas... claro que no, el riesgo es mucho y
> > además,, repito, cobramos por cantidad de empresas :)).
> >
> >
> >
> >
>
>