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:
Mostrar la cita

Hola, interlineado ;-)


Mostrar la cita

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
Mostrar la cita

la llamada a los sp's de cada BD. Los SP's trabajan sobre la propia BD

en
Mostrar la cita

que residen. El recorrido no lo hago en un SP, lo hago desde mi

aplicación,
Mostrar la cita

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.

Mostrar la cita

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
Mostrar la cita

pequeñas empresas y no más de 5 programadores, sólo digo que la

programación
Mostrar la cita

tiende a ser más compleja y propensa a errores por el simple hecho de

tener
Mostrar la cita

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.

Mostrar la cita

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?


Mostrar la cita

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
Mostrar la cita

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
Mostrar la cita

hacer cada vez una excepción de no filtrar la empresa cuando se trate de

una
Mostrar la cita

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

Mostrar la cita

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.


Mostrar la cita

Bueno, cuestion de opinion para mi tener que agregar un AND en cada WHERE

y
Mostrar la cita

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.

Mostrar la cita

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


Mostrar la cita

La ventaja para mi es que programo la aplicación simplemente ignorando el
parámetro "empresa", desarrollando así consultas, búsquedas,

combinaciones,
Mostrar la cita

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:
Mostrar la cita

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
Mostrar la cita

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

datos
Mostrar la cita

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
Mostrar la cita

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
Mostrar la cita

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
Mostrar la cita

>> 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
Mostrar la cita

> 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
Mostrar la cita

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

pasando
Mostrar la cita

> 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
Mostrar la cita

>> 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
Mostrar la cita

>> 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
Mostrar la cita

> 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?
Mostrar la cita

> 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
Mostrar la cita

>> 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
Mostrar la cita

> 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
Mostrar la cita

> 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
Mostrar la cita

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

*
Mostrar la cita

> 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
Mostrar la cita

> 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
Mostrar la cita

> 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
Mostrar la cita

> 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
Mostrar la cita

> 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
Mostrar la cita

>> 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
Mostrar la cita

>> excluir la necesidad de índices sobre la columna "empresa" sobre todo

en
Mostrar la cita

>> 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
Mostrar la cita

> 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

Mostrar la cita

Yo programo tambien con cursores del lado del cliente y

por un lado te
Mostrar la cita

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

lado por usar este
Mostrar la cita

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

aplicación. Por
Mostrar la cita

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

problemas de tráfico
Mostrar la cita

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

manipula los datos
Mostrar la cita

necesarios.

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

cliente, no estas
Mostrar la cita

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

cursores o como
Mostrar la cita

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

si yo desde mi
Mostrar la cita

aplicación puedo manipular con mayor facilidad los datos

por que no optar
Mostrar la cita

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

de los datos en el
Mostrar la cita

misamo servidor donde está SQL Server sin necesidad e

SP's, y por
Mostrar la cita

consiguiente con cero tráfico de red.

Con respecto a la arquitectura multiempresa, creo que las

opciones estan
Mostrar la cita

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

tablas de distintas
Mostrar la cita

BD, y decidir cual le conviene mas.


Saludos





"Maxi" wrote in message
news:
Mostrar la cita

Hola, interlineado ;-)


Mostrar la cita

Mala interpretacion. No tengo un SP de consolidación.

Hago el proceso
Mostrar la cita

Mostrar la cita

Mostrar la cita

desde mi aplicación (el front-end) que es unir los

resultados devueltos
Mostrar la cita

Mostrar la cita

por
Mostrar la cita

la llamada a los sp's de cada BD. Los SP's trabajan

sobre la propia BD
Mostrar la cita

Mostrar la cita

en
Mostrar la cita

que residen. El recorrido no lo hago en un SP, lo hago

desde mi
Mostrar la cita

Mostrar la cita

aplicación,
Mostrar la cita

en ésta también se programa no ? :)

Aja, bien o sea accedes a las tablas de tu sistema de

forma directa, con
Mostrar la cita

Mostrar la cita

el
inicio de sesion verdad. Como haces para que un usuario

(sesion) no acceda
Mostrar la cita

Mostrar la cita

a
esas mismas tablas desde un Excel? Ademas si no usas un

SP y estas pasando
Mostrar la cita

Mostrar la cita

la informacion al cliente estas saturando enormemente la

RED con datos
Mostrar la cita

Mostrar la cita

totalmente redundantes.

Mostrar la cita

No lo discuto, esos ERPs son super aplicaciones con

años de depuración y
Mostrar la cita

Mostrar la cita

Mostrar la cita

gran cantidad de personal de control de calidad. Pero

para los que
Mostrar la cita

Mostrar la cita

tenemos
Mostrar la cita

pequeñas empresas y no más de 5 programadores, sólo

digo que la
Mostrar la cita

Mostrar la cita

programación
Mostrar la cita

tiende a ser más compleja y propensa a errores por el

simple hecho de
Mostrar la cita

Mostrar la cita

tener
Mostrar la cita

que filtrar cada query con la columna "empresa". Y si

aparte de
Mostrar la cita

Mostrar la cita

Mostrar la cita

empresa,
ya tenemos una variable como "Division" o "Centro de

Costo", solo hay que
Mostrar la cita

Mostrar la cita

Mostrar la cita

imaginarse:)

Tu sistemas hoy puede ser pequeño pero mañana enorme, no

puedes copiar
Mostrar la cita

Mostrar la cita

todo
lo que hacen los grandes, pero si vas a trabajar con

SQL-Server te aseguro
Mostrar la cita

Mostrar la cita

que estas tecnicas las tiene un sistemita pequeño

tambien!! ahora si
Mostrar la cita

Mostrar la cita

trabajas con Fox o Access la historia es otra.

Mostrar la cita

Error.. No hay un SP de consolidacion, como digo

arriba. Consolido los
Mostrar la cita

Mostrar la cita

Mostrar la cita

resultados en la aplicación.

Vuelvo a repetir, pasas todos los datos de un lado al

otro (saturando
Mostrar la cita

Mostrar la cita

enormemente la RED).

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

imaginas porque?
Mostrar la cita

Mostrar la cita

justamente para que los developer no hagan tu tecnica

que es para nada
Mostrar la cita

Mostrar la cita

recomendada. Porque tener las cosas duplicadas si ya

estan en un
Mostrar la cita

Mostrar la cita

repositorio?
Porque saturar la RED?


Mostrar la cita

Claro que sí porque la integridad referencial es dentro

de las tablas de
Mostrar la cita

Mostrar la cita

Mostrar la cita

cada BD. Ahora bien, si es que hablas de tablas

comunes a varias
Mostrar la cita

Mostrar la cita

Mostrar la cita

empresas, bueno ya eso es otra cosa pero, puedes

tenerlas en la base de
Mostrar la cita

Mostrar la cita

Mostrar la cita

datos del sistema que seria otra o en su defecto copiar

los datos a
Mostrar la cita

Mostrar la cita

Mostrar la cita

medida
que se modifiquen. Normalmente las tablas que se hacen

comunes no son
Mostrar la cita

Mostrar la cita

tablas
Mostrar la cita

de operaciones, sino tablas maestras como de clientes,

articulos, etc..
Mostrar la cita

Mostrar la cita

Mostrar la cita

Pero para tu caso, teniendo todo junto, me imagino que

sería más
Mostrar la cita

Mostrar la cita

complicado
Mostrar la cita

hacer cada vez una excepción de no filtrar la empresa

cuando se trate de
Mostrar la cita

Mostrar la cita

una
Mostrar la cita

tabla comun.

Si la de las mismas BDD ok pero las tablas compartidas

no, por lo cual o
Mostrar la cita

Mostrar la cita

debes aplicar TR con los problemas de mantenimiento que

lleva no. En sql2k
Mostrar la cita

Mostrar la cita

la forma natural de hacer Integridad referencial es por

medio de Claves
Mostrar la cita

Mostrar la cita

Externas y no por TR

Mostrar la cita

Es claro.. Eso no se discute. Hablé de una

manipulación local en Visual
Mostrar la cita

Mostrar la cita

Mostrar la cita

Foxpro de datos devueltos desde el servidor SQL. Esta

manipulación
Mostrar la cita

Mostrar la cita

Mostrar la cita

aunque
afecta el desempeño final para el usuario, no afecta el

rendimiento del
Mostrar la cita

Mostrar la cita

Mostrar la cita

servidor que interfiera con los demás usuarios.

Seguro que no afecta el servidor? pone un contador de

transferencias de
Mostrar la cita

Mostrar la cita

RED
y contame ;-). Lo afecta porque estas haciendo pasar los

datos completos
Mostrar la cita

Mostrar la cita

de
un lado al otro por tu RED y seguramente si estas

haciendo muchos SELECT *
Mostrar la cita

Mostrar la cita

FROM el servidor esta haciendo Table Scan y esto afecta

enormemente el
Mostrar la cita

Mostrar la cita

rendimiento del servidor.


Mostrar la cita

Bueno, cuestion de opinion para mi tener que agregar un

AND en cada WHERE
Mostrar la cita

Mostrar la cita

y
Mostrar la cita

cada JOIN para incluir la empresa me parece complicado

y aumenta la
Mostrar la cita

Mostrar la cita

Mostrar la cita

posibilidad de errores, aunque entiendo que pueda ser

lo ideal tenerlo
Mostrar la cita

Mostrar la cita

así.

El tema aca no se trata de si es complicado para el

developer o no, si
Mostrar la cita

Mostrar la cita

estas
montando tu sistema en un SQL-Server (motor de Base de

Datos Relacional)
Mostrar la cita

Mostrar la cita

lo
que debes hacer es que este recurso sumamente critico y

un gran cuello de
Mostrar la cita

Mostrar la cita

botella funcione de la mejor forma posible. Ademas pensa

que en una
Mostrar la cita

Mostrar la cita

empresa
no solo puede estar tu sistema, quizas en ese servidor

tengan BDD de otros
Mostrar la cita

Mostrar la cita

sistemas y si el tuyo afecta al rendimiento global del

servidor, vos que
Mostrar la cita

Mostrar la cita

pensas que puede pasar?

Tu punto de vista es valido para Fox que no es una BDD

corporativa, ahora
Mostrar la cita

Mostrar la cita

en
ambientes corporativos no se debe trabajar asi.

Mostrar la cita

Bueno, amigo, aunque lo digas como si fuera una

sentencia, la tuya es
Mostrar la cita

Mostrar la cita

Mostrar la cita

también una opinión subjetiva, igual que la mia. La

respeto pero no la
Mostrar la cita

Mostrar la cita

Mostrar la cita

comparto.

Subjetiva? te parece? yo te di miles de razones por las

que no es
Mostrar la cita

Mostrar la cita

aconsejable hacer todas las tecnicas que vos estas

exponiendo :-)
Mostrar la cita

Mostrar la cita

Mostrar la cita

La ventaja para mi es que programo la aplicación

simplemente ignorando el
Mostrar la cita

Mostrar la cita

Mostrar la cita

parámetro "empresa", desarrollando así consultas,

búsquedas,
Mostrar la cita

Mostrar la cita

combinaciones,
Mostrar la cita

sp's, más sencillos que permitan mejor RAD y menos

posibilidad de
Mostrar la cita

Mostrar la cita

Mostrar la cita

cometer
errores. Eso para mi es más que suficiente ventaja.

Otra ventaja sería
Mostrar la cita

Mostrar la cita

Mostrar la cita

excluir la necesidad de índices sobre la columna

"empresa" sobre todo en
Mostrar la cita

Mostrar la cita

Mostrar la cita

tablas de muchos registros, peor aún si ya existe otra

variable como
Mostrar la cita

Mostrar la cita

Mostrar la cita

"division" o "centro de costo".

Bien , es una ventaja para el developer verdad? ahora si

usaras SP que es
Mostrar la cita

Mostrar la cita

lo
que se deberia utilizar para consolidar por ej, ya las

"ventajas" no son
Mostrar la cita

Mostrar la cita

tantas, porque como te dije antes, deberias ir cambiando

el SP mientras
Mostrar la cita

Mostrar la cita

agregas empresas o borras.

Digamos que en tu forma de trabajar es logico tu

razonamiento, pero como
Mostrar la cita

Mostrar la cita

no
estas aplicando muchas de las buenas practicas

recomendadas de BDD (en
Mostrar la cita

Mostrar la cita

Sql-Server) es como que el unico sustento que tienen es

la comodidad a
Mostrar la cita

Mostrar la cita

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
Mostrar la cita

Mostrar la cita

.

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:%
Mostrar la cita

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:
Mostrar la cita

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
Mostrar la cita

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

datos
Mostrar la cita

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
Mostrar la cita

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
Mostrar la cita

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
Mostrar la cita

>> 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
Mostrar la cita

> 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
Mostrar la cita

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

pasando
Mostrar la cita

> 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
Mostrar la cita

>> 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
Mostrar la cita

>> 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
Mostrar la cita

> 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?
Mostrar la cita

> 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
Mostrar la cita

>> 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
Mostrar la cita

> 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
Mostrar la cita

> 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
Mostrar la cita

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

*
Mostrar la cita

> 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
Mostrar la cita

> 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
Mostrar la cita

> 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
Mostrar la cita

> 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
Mostrar la cita

> 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
Mostrar la cita

>> 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
Mostrar la cita

>> excluir la necesidad de índices sobre la columna "empresa" sobre todo

en
Mostrar la cita

>> 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
Mostrar la cita

> 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:
Mostrar la cita

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
Mostrar la cita

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.
Mostrar la cita

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
Mostrar la cita

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
Mostrar la cita

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
Mostrar la cita

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

llenes
Mostrar la cita

> 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
Mostrar la cita

> 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.
Mostrar la cita

>
> 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
Mostrar la cita

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

si
Mostrar la cita

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

una
Mostrar la cita

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

buee
Mostrar la cita

> 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
Mostrar la cita

> 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
Mostrar la cita

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

deban
Mostrar la cita

> 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
Mostrar la cita

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

Por
Mostrar la cita

>> 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
Mostrar la cita

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

optar
Mostrar la cita

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

en
Mostrar la cita

> 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
Mostrar la cita

>> 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
Mostrar la cita

> 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
Mostrar la cita

>> > totalmente redundantes.
>> >
>> >>
>> >> No lo discuto, esos ERPs son super aplicaciones con años de

depuración
Mostrar la cita

> 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
Mostrar la cita

>> > 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
Mostrar la cita

> que
>> >> imaginarse:)
>> >>
>> >
>> > Tu sistemas hoy puede ser pequeño pero mañana enorme, no puedes

copiar
Mostrar la cita

>> > 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
Mostrar la cita

>> >> 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
Mostrar la cita

>> > 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
Mostrar la cita

> 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
Mostrar la cita

>> > 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
Mostrar la cita

> de
>> > una
>> >> tabla comun.
>> >
>> > Si la de las mismas BDD ok pero las tablas compartidas no, por lo

cual
Mostrar la cita

>> > 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
Mostrar la cita

>> > 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
Mostrar la cita

>> > 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
Mostrar la cita

>> > 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
Mostrar la cita

>> > así.
>> >
>> > El tema aca no se trata de si es complicado para el developer o no,

si
Mostrar la cita

>> > 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
Mostrar la cita

> 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
Mostrar la cita

>> >> también una opinión subjetiva, igual que la mia. La respeto pero no

la
Mostrar la cita

>> >> 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
Mostrar la cita

> 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
Mostrar la cita

> 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
Mostrar la cita

> 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
Mostrar la cita

>> > 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
Mostrar la cita

>> > Sql-Server) es como que el unico sustento que tienen es la comodidad

a
Mostrar la cita

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