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".

Hola Ricardo.

Aunque yo no puedo quizas opinar a profundidad porque no tengo mucha
experiencia me parece logico eso que dices en mi caso las empresas son
totalmente independientes osea no hay tablas compartidas. Por tanto pienso
que se aplica mejor a mi caso tener bases separadas por empresas.


Berta Gomez


"Ricardo Passians" wrote in message
news:

>
> 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".

ok Ricardo, no usas SP por lo que veo que estas accediendo a las tablas de
forma directa verdad? bueno aca vamos a seguir discutiendo porque para mi no
es ideal que una sesion acceda a la tabla de forma directa.

Desarrollar las consultas en la aplicacion haran que la misma sea lenta e
insegura, pero si haces eso entonces el logico tu razonamiento de dividir
las BDD por empresa ;-)

Y disculpame una opinion: yo tambien desarrollo sistemas pequeños, pero no
por eso voy a dejar las buenas practicas de programacion de lado, que
pasaria si tu sistema mañana crece mucho? el proceso de consolidacion se
transformaria en un cuello de botella bastante importante no?

Pero bueno, no usas SP y usas cursores del lado del cliente

Creo que nada mas por decir... quizas algun guru de este news se prenda en
la discusion :-)




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:

>
> 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".

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

Berta, entonces lo que vos estas pidiendo en multibase y no multiempresa
:-p, son 2 cosas totalmente distintas y si es multibase (o sea que el
sistema pueda tener mas de una BDD con la que puedas trabajar).


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



"Berta Gomez" escribió en el mensaje
news:

Hola Ricardo.

Aunque yo no puedo quizas opinar a profundidad porque no tengo mucha
experiencia me parece logico eso que dices en mi caso las empresas son
totalmente independientes osea no hay tablas compartidas. Por tanto pienso
que se aplica mejor a mi caso tener bases separadas por empresas.


Berta Gomez


"Ricardo Passians" wrote in message
news:
> >
> > 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".
>
>

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

Hola, interlineado ;-)

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 ? :)

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.

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).

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.

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í.

El tema aca no se trata de si es complicado para el developer o no, si estas
montando tu sistema en un SQL-Server (motor de Base de Datos Relacional) lo
que debes hacer es que este recurso sumamente critico y un gran cuello de
botella funcione de la mejor forma posible. Ademas pensa que en una empresa
no solo puede estar tu sistema, quizas en ese servidor tengan BDD de otros
sistemas y si el tuyo afecta al rendimiento global del servidor, vos que
pensas que puede pasar?

Tu punto de vista es valido para Fox que no es una BDD corporativa, ahora en
ambientes corporativos no se debe trabajar asi.

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.

Subjetiva? te parece? yo te di miles de razones por las que no es
aconsejable hacer todas las tecnicas que vos estas exponiendo :-)

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".

Bien , es una ventaja para el developer verdad? ahora si usaras SP que es lo
que se deberia utilizar para consolidar por ej, ya las "ventajas" no son
tantas, porque como te dije antes, deberias ir cambiando el SP mientras
agregas empresas o borras.

Digamos que en tu forma de trabajar es logico tu razonamiento, pero como no
estas aplicando muchas de las buenas practicas recomendadas de BDD (en
Sql-Server) es como que el unico sustento que tienen es la comodidad a costa
de Seguridad y Performance.

Un fuerte abrazo



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