Re: Sistema multiempresa

Yo programo tambien con cursores del lado del cliente y por un lado te
cuento que la seguridad de la aplicación no se deja de lado por usar este
método, podes por ejemplo utilizar seguridad por roles de aplicación. Por
otro lado si la aplicación esta bien diseñda no tienes problemas de tráfico
de red ya que una buena aplicación cliente-servidor solo manipula los datos
necesarios.

Si en tu aplicación haces un query y lo muestreas al cliente, no estas
trayendo acaso los datos a travez de la red? , llamalo cursores o como
quieras pero el tráfico de la red es el mismo. Ahora bien si yo desde mi
aplicación puedo manipular con mayor facilidad los datos por que no optar
con cursores del lado del cliente?
Ademas para que te informes yo puedo manipular el grueso de los datos en el
misamo servidor donde está SQL Server sin necesidad e SP's, y por
consiguiente con cero tráfico de red.

Con respecto a la arquitectura multiempresa, creo que las opciones estan
claras, cada uno deberá evaluar según la interacción de tablas de distintas
BD, y decidir cual le conviene mas.


Saludos





"Maxi" wrote in message
news:

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

Daniel, con los Roles de aplicacion solucionas en parte el problema de
seguridad.

Pero a lo que yo iba es a otra cosa: Si traes la informacion completa y
luego la compilas en tu cliente, esto es lento y no recomendado. Lo ideal
seria que llames a un SP que te arme lo necesario y que con este SP llenes
un Dataset por ej.

El metodo de cursores es un metodo que los developer van a tener que empezar
a olvidar un poco!! no es nada facil porque desde hace muchos años se
trabaja con este tipo de tecnicas que para las BDD del momento han
funcionado de mil maravillas!! Ahora cuando saltas a un ambiente corporativo
la cosa cambia radicalmente te lo aseguro.

Muchas de las querys las podes armar en un SP y trabajando con conjunto de
datos y no con cursores. Esto hara que las respuestas sean eficienrtes y
ademas al ser un SP es seguro y lo podes reutilizar desde otra aplicacion.

Creo que la diferencia en tu modelo radica en esto:

Si tenes multibase y no usas SP (como dijo el amigo) va a tener que
programar todo en la aplicacion, esto quiere decir que cuando quiera
consolidar va a tener o que armar una query grande o armar varias querys
llenar el Dataset y procesar.

Todo esto es muy malo para SQL-Server, claro es muy bueno para el developer
y por eso lo hace:

Es malo por lo siguiente:

1) Si arma una gran query el motor esta compilando cada vez que la ejecute
(imaginate si 3 usuarios lo hacen al mismo tiempo) y no usara la cache, si
tiene un SP este no volvera a compilar a menos que se lo indiques y es una
mejora considerable en el rendimiento

2) Si arma mas de una query y llena los Dataset para luego procesar, buee
aca ademas del problema anterior (punto 1) se suma una gran carga de trafico
de red y una duplicacion de la informacion (en un cliente esto puede ser
mortal, imaginate un portalweb armado asi?)


Claro esta, esta es la opinion y experiencia mia (y creo que de muchos mas
de este news) con respecto a trabajar en SQL-Server y entornos corporativos.

Es dificil cambiar el paradigma pero siempre hay que pensar en que tecnicas
son buenas para SQL-Server y no cuales son mas faciles de usar para los
developer!! y te comento mas, algunas empresas usan Standares para que si
armas vos una aplicacion que correra sobre uno de sus servidores SQL deban
cumplir con algunos requisitos :-)

Pero bue... yo solo les comento que es segun mi experiencia en ambientes
corporativos lo mejor, ustedes tienen vuestro punto de vista y es totalmente
valido.



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



"Daniel Durand" escribió en el mensaje
news:

Yo programo tambien con cursores del lado del cliente y por un lado te
cuento que la seguridad de la aplicación no se deja de lado por usar este
método, podes por ejemplo utilizar seguridad por roles de aplicación. Por
otro lado si la aplicación esta bien diseñda no tienes problemas de

tráfico

de red ya que una buena aplicación cliente-servidor solo manipula los

datos

necesarios.

Si en tu aplicación haces un query y lo muestreas al cliente, no estas
trayendo acaso los datos a travez de la red? , llamalo cursores o como
quieras pero el tráfico de la red es el mismo. Ahora bien si yo desde mi
aplicación puedo manipular con mayor facilidad los datos por que no optar
con cursores del lado del cliente?
Ademas para que te informes yo puedo manipular el grueso de los datos en

el

misamo servidor donde está SQL Server sin necesidad e SP's, y por
consiguiente con cero tráfico de red.

Con respecto a la arquitectura multiempresa, creo que las opciones estan
claras, cada uno deberá evaluar según la interacción de tablas de

distintas

BD, y decidir cual le conviene mas.


Saludos





"Maxi" wrote in message
news:
> 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
>
>

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

A mi parecer el manejo de la consolidación sea desde el
lado del servidor o desde un componente son opciones
válidas, el tema es si debe existir esa consolidación o no,
pero volviendo a la pregunta inicial de si separar las
bases de datos por empresa o mantenerlas juntas, la gran
mayoría de aplicaciones que he visto los mantiene juntas en
primer lugar porque si uno de los requerimientos es que sea
multiempresa lo más natural cuando realizas el modelamiento
de tu BD es incluir el campo de empresa, adicionalmente
esto facilita el mantenimiento ya que no tienes que estar
modificando todos las BBDD cuando cambia el diseño de
alguna tabla o se modifique un procedimiento almacenado,
por el lado de programación, si se tiene desde un inicio un
esquema de la BD y un manual de desarrollo donde se
especifique que cosas se deben tomar en cuenta en el
momento de la programación el incluir un campo o más en las
consultas no es para nada complejo.

Saludos,
Ulises

Yo programo tambien con cursores del lado del cliente y

por un lado te

cuento que la seguridad de la aplicación no se deja de

lado por usar este

método, podes por ejemplo utilizar seguridad por roles de

aplicación. Por

otro lado si la aplicación esta bien diseñda no tienes

problemas de tráfico

de red ya que una buena aplicación cliente-servidor solo

manipula los datos

necesarios.

Si en tu aplicación haces un query y lo muestreas al

cliente, no estas

trayendo acaso los datos a travez de la red? , llamalo

cursores o como

quieras pero el tráfico de la red es el mismo. Ahora bien

si yo desde mi

aplicación puedo manipular con mayor facilidad los datos

por que no optar

con cursores del lado del cliente?
Ademas para que te informes yo puedo manipular el grueso

de los datos en el

misamo servidor donde está SQL Server sin necesidad e

SP's, y por

consiguiente con cero tráfico de red.

Con respecto a la arquitectura multiempresa, creo que las

opciones estan

claras, cada uno deberá evaluar según la interacción de

tablas de distintas

BD, y decidir cual le conviene mas.


Saludos





"Maxi" wrote in message
news:

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

.

Maxi, en realidad aprecio tu punto de vista y me interesa confrontarlo con
el mío para sacar conclusiones. Yo creo que quizas estas generalizando un
poco el uso de los cursores, ya que depende de la arquitectura de la
aplicacióm, en el caso mío no tengo mucha experiencia en sistemas
corporativos, pero he hecho algunos y hasta ahora no tenemos problemas. Te
cuento que todos los procesos "pesados" se realizan en el servidor y lo
único que viaja al cliente es un XML, que en este caso es similar o mejor
que un dataset ya que se trata de texto plano. Ademas estos datos no viajan
completos sino solo los necesarios. El cliente interpreta este XML que ya
viene procesado y lo manipula.

Si tuvieramos problemas con el rendimiento solo potenciamos los servidores.
Asi que creo que eventualmente no habran problemas de rendimiento. Pues
entonces cual sería el problema ?, aún no lo comprendo.
Quizás sea por que no interpreto a que te refieres con que la información se
complila en el cliente.

Por otro lado en tu caso si el usuario decide cambiar de motor de bases de
datos estas frito.
En al caso mío solo tengo que cambiar la cadena de conexión y puedo cambiar
de base de datos, y si quisiera cambiar de front-end tampoco sería muy
problematico, ya que todo el proceso se ejecuta en el servidor a travez de
DLL's que procesan todos los datos.

Y todo esto con Visual FoxPro, aunque no lo creas.


Saludos




"Maxi" wrote in message
news:%

Daniel, con los Roles de aplicacion solucionas en parte el problema de
seguridad.

Pero a lo que yo iba es a otra cosa: Si traes la informacion completa y
luego la compilas en tu cliente, esto es lento y no recomendado. Lo ideal
seria que llames a un SP que te arme lo necesario y que con este SP llenes
un Dataset por ej.

El metodo de cursores es un metodo que los developer van a tener que
empezar
a olvidar un poco!! no es nada facil porque desde hace muchos años se
trabaja con este tipo de tecnicas que para las BDD del momento han
funcionado de mil maravillas!! Ahora cuando saltas a un ambiente
corporativo
la cosa cambia radicalmente te lo aseguro.

Muchas de las querys las podes armar en un SP y trabajando con conjunto de
datos y no con cursores. Esto hara que las respuestas sean eficienrtes y
ademas al ser un SP es seguro y lo podes reutilizar desde otra aplicacion.

Creo que la diferencia en tu modelo radica en esto:

Si tenes multibase y no usas SP (como dijo el amigo) va a tener que
programar todo en la aplicacion, esto quiere decir que cuando quiera
consolidar va a tener o que armar una query grande o armar varias querys
llenar el Dataset y procesar.

Todo esto es muy malo para SQL-Server, claro es muy bueno para el
developer
y por eso lo hace:

Es malo por lo siguiente:

1) Si arma una gran query el motor esta compilando cada vez que la ejecute
(imaginate si 3 usuarios lo hacen al mismo tiempo) y no usara la cache, si
tiene un SP este no volvera a compilar a menos que se lo indiques y es una
mejora considerable en el rendimiento

2) Si arma mas de una query y llena los Dataset para luego procesar, buee
aca ademas del problema anterior (punto 1) se suma una gran carga de
trafico
de red y una duplicacion de la informacion (en un cliente esto puede ser
mortal, imaginate un portalweb armado asi?)


Claro esta, esta es la opinion y experiencia mia (y creo que de muchos mas
de este news) con respecto a trabajar en SQL-Server y entornos
corporativos.

Es dificil cambiar el paradigma pero siempre hay que pensar en que
tecnicas
son buenas para SQL-Server y no cuales son mas faciles de usar para los
developer!! y te comento mas, algunas empresas usan Standares para que si
armas vos una aplicacion que correra sobre uno de sus servidores SQL deban
cumplir con algunos requisitos :-)

Pero bue... yo solo les comento que es segun mi experiencia en ambientes
corporativos lo mejor, ustedes tienen vuestro punto de vista y es
totalmente
valido.



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



"Daniel Durand" escribió en el mensaje
news:

Yo programo tambien con cursores del lado del cliente y por un lado te
cuento que la seguridad de la aplicación no se deja de lado por usar este
método, podes por ejemplo utilizar seguridad por roles de aplicación. Por
otro lado si la aplicación esta bien diseñda no tienes problemas de

tráfico

de red ya que una buena aplicación cliente-servidor solo manipula los

datos

necesarios.

Si en tu aplicación haces un query y lo muestreas al cliente, no estas
trayendo acaso los datos a travez de la red? , llamalo cursores o como
quieras pero el tráfico de la red es el mismo. Ahora bien si yo desde mi
aplicación puedo manipular con mayor facilidad los datos por que no optar
con cursores del lado del cliente?
Ademas para que te informes yo puedo manipular el grueso de los datos en

el

misamo servidor donde está SQL Server sin necesidad e SP's, y por
consiguiente con cero tráfico de red.

Con respecto a la arquitectura multiempresa, creo que las opciones estan
claras, cada uno deberá evaluar según la interacción de tablas de

distintas

BD, y decidir cual le conviene mas.


Saludos





"Maxi" wrote in message
news:
> 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
>
>

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

Daniel, confrontar es muy bueno :-)

A ver, los cursores no son la muerte, solo que son poco eficientes :(

Un servidor para una empresa es un recurso muy costoso y por tal motivo debe
tenerlo aceitadito 100%.

Si no aplicas algunas tecnicas de programacion esto no sucedera, ademas como
mencione antes, al trabajar en un ambiente corporativo como es SQLserver, es
muy pero muy probable que en ese mismo servidor existan otras aplicaciones,
con lo cual entre todas deben hacer un EXCELENTE uso de los recursos de la
forma mas eficiente posible.

Ahora, quizas en tu diseño (no lo conozco en profundidad como para poder dar
una mejor aproximacion) no tengas problemas, quizas este bien diseñado y
utilices grupos de registros y no cursores, pero una cosa que no podes
pensar es que si la cosa se pone lenta le vas a agregar mas recursos al
servidor!! esto es una cuestion que no se puede hacer tan asi y ademas en
muchos de los casos es sumanente costoso para tu cliente a menos que vos le
regales los Update no ;-)

Te comento que he realizado algunos analisis a sistemas que le decian al
cliente que necesitaban un pentium 10 con 100GB de ram para correr, cosa que
el cliente se nego rotundamente, y que luego de hacer un analisis y mejora
de los procesos, no ha gastado ni un solo $ en actualizar su hard y la
velocidad del sistema canbio de forma considerable, en algunos puntos hasta
un 400% superior.

Ahora sigamos, vos no queres depender de la BDD, bue aca vamos a discutir
nuevamente, ese concepto te lo acepto para cuando usas Fox, Access, Mysql, o
algun otro, pero si tu repositorio es SQL - Oracle u Db2 ese concepto no es
muy bueno porque por hacer un sistema multiplataformadebase estas dejando
muchas cosas de lado (Performance sobre todo)

Si lo quieres hacer multiplataformadebdd lo unico que tienes que hacer es
cambiar la capa de acceso a datos, en la cual podra llamar a otros SP o
directamente no llamar a ninguno si el caso es una BDD que no disponga de
SP.

Pero te comento, conozco muchos sistemas de todos los tamaños, y cuando lo
arman para entornos corporativos lo que hacen es tener los SP de cada motor
que necesiten.

Pero te repito si programas en capas, con solo cambiar la capa de acceso a
datos ya estas. Ademas cuantas veces en la vida de un sistema cambia el
repositorio? todos los dias? cada 1 semana? y cuantas veces un usuario
ejecuta una query? Porque por hacer que el sistema pueda soportar mas de una
BDD (que ocurre muy poco en la vida del sistema en el cliente) por dejar de
lado el aprovechamiento del servidor (cosa que el usuario ve todos los dias)
me parece que hay una cosa muy dispar!! y como dije antes, los sistemas que
quieren ser multiplataformadebdd al final no terminan funcionando en ningun
lado bien, a menos que hagas las cosas como corresponde y por cada
plataforma de BDD armes los SP correspondientes.

Pero bueno, quizas hoy no tengas ningun problema, quizas tengas la suerte de
no tenerlo nunca, pero eso no quita las buenas tecnicas de programacion que
ademas han sido probadas.

Quizas tus sistemas no esten usando el servidor completo, o quizas tus
clientes ven como normal que el dia de mañana si el sistema se pone lento
hay que invertir Dls en actualizar Hard!! pero esto no es lo normal, si tu
sistema no esta bien diseñado y la performance pasa a ser un problema, a la
larga o a la corta te quedaras sin el cliente, y quizas solo sucedio esto
por un mas desarrollo :(

Yo en mi forma de pensar hago esto: si el sistema es para 10 usuarios y 1gb
de data, lo pienso para 100 y 10GB de data como minimo!! porque seguramente
en algun momento llegue a ese punto y no me gustaria decirle a mi cliente
que ahora debe cambiar todo el servidor porque sino la cosa seguira lenta
:-)

Bue, perdon por semejante mail pero considere que era oportuno aclarar los
puntos. Quizas alguno mas le guste aportar algo a este interesante debate
que estamos teniendo :-)

Un fuerte abrazo




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



"Daniel Durand" escribió en el mensaje
news:

Maxi, en realidad aprecio tu punto de vista y me interesa confrontarlo con
el mío para sacar conclusiones. Yo creo que quizas estas generalizando un
poco el uso de los cursores, ya que depende de la arquitectura de la
aplicacióm, en el caso mío no tengo mucha experiencia en sistemas
corporativos, pero he hecho algunos y hasta ahora no tenemos problemas. Te
cuento que todos los procesos "pesados" se realizan en el servidor y lo
único que viaja al cliente es un XML, que en este caso es similar o mejor
que un dataset ya que se trata de texto plano. Ademas estos datos no

viajan

completos sino solo los necesarios. El cliente interpreta este XML que ya
viene procesado y lo manipula.

Si tuvieramos problemas con el rendimiento solo potenciamos los

servidores.

Asi que creo que eventualmente no habran problemas de rendimiento. Pues
entonces cual sería el problema ?, aún no lo comprendo.
Quizás sea por que no interpreto a que te refieres con que la información

se

complila en el cliente.

Por otro lado en tu caso si el usuario decide cambiar de motor de bases de
datos estas frito.
En al caso mío solo tengo que cambiar la cadena de conexión y puedo

cambiar

de base de datos, y si quisiera cambiar de front-end tampoco sería muy
problematico, ya que todo el proceso se ejecuta en el servidor a travez de
DLL's que procesan todos los datos.

Y todo esto con Visual FoxPro, aunque no lo creas.


Saludos




"Maxi" wrote in message
news:%
> Daniel, con los Roles de aplicacion solucionas en parte el problema de
> seguridad.
>
> Pero a lo que yo iba es a otra cosa: Si traes la informacion completa y
> luego la compilas en tu cliente, esto es lento y no recomendado. Lo

ideal

> seria que llames a un SP que te arme lo necesario y que con este SP

llenes

> un Dataset por ej.
>
> El metodo de cursores es un metodo que los developer van a tener que
> empezar
> a olvidar un poco!! no es nada facil porque desde hace muchos años se
> trabaja con este tipo de tecnicas que para las BDD del momento han
> funcionado de mil maravillas!! Ahora cuando saltas a un ambiente
> corporativo
> la cosa cambia radicalmente te lo aseguro.
>
> Muchas de las querys las podes armar en un SP y trabajando con conjunto

de

> datos y no con cursores. Esto hara que las respuestas sean eficienrtes y
> ademas al ser un SP es seguro y lo podes reutilizar desde otra

aplicacion.

>
> Creo que la diferencia en tu modelo radica en esto:
>
> Si tenes multibase y no usas SP (como dijo el amigo) va a tener que
> programar todo en la aplicacion, esto quiere decir que cuando quiera
> consolidar va a tener o que armar una query grande o armar varias querys
> llenar el Dataset y procesar.
>
> Todo esto es muy malo para SQL-Server, claro es muy bueno para el
> developer
> y por eso lo hace:
>
> Es malo por lo siguiente:
>
> 1) Si arma una gran query el motor esta compilando cada vez que la

ejecute

> (imaginate si 3 usuarios lo hacen al mismo tiempo) y no usara la cache,

si

> tiene un SP este no volvera a compilar a menos que se lo indiques y es

una

> mejora considerable en el rendimiento
>
> 2) Si arma mas de una query y llena los Dataset para luego procesar,

buee

> aca ademas del problema anterior (punto 1) se suma una gran carga de
> trafico
> de red y una duplicacion de la informacion (en un cliente esto puede ser
> mortal, imaginate un portalweb armado asi?)
>
>
> Claro esta, esta es la opinion y experiencia mia (y creo que de muchos

mas

> de este news) con respecto a trabajar en SQL-Server y entornos
> corporativos.
>
> Es dificil cambiar el paradigma pero siempre hay que pensar en que
> tecnicas
> son buenas para SQL-Server y no cuales son mas faciles de usar para los
> developer!! y te comento mas, algunas empresas usan Standares para que

si

> armas vos una aplicacion que correra sobre uno de sus servidores SQL

deban

> cumplir con algunos requisitos :-)
>
> Pero bue... yo solo les comento que es segun mi experiencia en ambientes
> corporativos lo mejor, ustedes tienen vuestro punto de vista y es
> totalmente
> valido.
>
>
>
> 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
>
>
>
> "Daniel Durand" escribió en el mensaje
> news:
>> Yo programo tambien con cursores del lado del cliente y por un lado te
>> cuento que la seguridad de la aplicación no se deja de lado por usar

este

>> método, podes por ejemplo utilizar seguridad por roles de aplicación.

Por

>> otro lado si la aplicación esta bien diseñda no tienes problemas de
> tráfico
>> de red ya que una buena aplicación cliente-servidor solo manipula los
> datos
>> necesarios.
>>
>> Si en tu aplicación haces un query y lo muestreas al cliente, no estas
>> trayendo acaso los datos a travez de la red? , llamalo cursores o como
>> quieras pero el tráfico de la red es el mismo. Ahora bien si yo desde

mi

>> aplicación puedo manipular con mayor facilidad los datos por que no

optar

>> con cursores del lado del cliente?
>> Ademas para que te informes yo puedo manipular el grueso de los datos

en

> el
>> misamo servidor donde está SQL Server sin necesidad e SP's, y por
>> consiguiente con cero tráfico de red.
>>
>> Con respecto a la arquitectura multiempresa, creo que las opciones

estan

>> claras, cada uno deberá evaluar según la interacción de tablas de
> distintas
>> BD, y decidir cual le conviene mas.
>>
>>
>> Saludos
>>
>>
>>
>>
>>
>> "Maxi" wrote in message
>> news:
>> > 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
>> >
>> >
>>
>>
>
>
>
> 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
>
>

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