Re: Sistema multiempresa

Un gusto

Saludos

"Maxi" wrote in message
news:

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

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

el

inicio de sesion verdad. Como haces para que un usuario (sesion) no acceda

a

esas mismas tablas desde un Excel? Ademas si no usas un SP y estas pasando
la informacion al cliente estas saturando enormemente la RED con datos
totalmente redundantes.

Sobre lo de excel no entendí.
Pero por lo de sp y saturación estás totalmente equivocado. Cuáles datos
redundantes ? Piensas que hago DW ? Parece como si estuviéramos hablando de
cosas diferentes. Estoy hablando de consolidar resultados obtenidos
independientemente de cada BD/empresa. Ok... es algo mas lento que tenerlo
todo junto, lo digo arriba. Pero no es algo de vida o muerte pues los
usuarios NO CONSOLIDAN a diario. Ademas cuando tiran un reporte No
consolidado los resultados del SP de la BD circulan al cliente... cual es
el problema que para consolidar se repita este proceso para cada BD?

Aclaro de nuevo. No es que no uso SP's.. Es que no uso uno para CONSOLIDAR.
Pero cada BD tiene sus SP's para extraer los datos y devolvermelos al front
end y los combino (o los UNO, mejor dicho) ya en la aplicación en tablas
temporales locales, las cuales maneja VFP mejor que cualquier lenguaje. Pero
estos cursores (tablas temporales) de visual foxpro NO TIENEN NADA QUE VER
con los cursores de SQL Server ni con los de ADO.NET, cursores que parecen
ser tu fijación y creo que es de donde viene la malinterpretación.
Si te interesa aclarar mejor la confusión investiga por ahí sobre las tablas
temporales locales de VFP.

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

>
> No lo discuto, esos ERPs son super aplicaciones con años de depuración y
> gran cantidad de personal de control de calidad. Pero para los que
tenemos
> pequeñas empresas y no más de 5 programadores, sólo digo que la
programación
> tiende a ser más compleja y propensa a errores por el simple hecho de
tener
> que filtrar cada query con la columna "empresa". Y si aparte de

empresa,

> ya tenemos una variable como "Division" o "Centro de Costo", solo hay

que

> imaginarse:)
>

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

todo

lo que hacen los grandes, pero si vas a trabajar con SQL-Server te aseguro
que estas tecnicas las tiene un sistemita pequeño tambien!! ahora si
trabajas con Fox o Access la historia es otra.


> Error.. No hay un SP de consolidacion, como digo arriba. Consolido los
> resultados en la aplicación.

Vuelvo a repetir, pasas todos los datos de un lado al otro (saturando
enormemente la RED).

Estas muy equivocado insisto. Recuerda que estoy hablando de un caso real y
comprobado. Si fuese como dices ya los usuarios hubiesen gritado y para el
caso que me ocupa no es que sean tantos pero son cerca de 100. Lo que pasa
es que Visual Foxpro nos da la ventaja de tener tablas locales temporales
(en el cliente) donde hacer cosas con los resultados que nos devuelve SQL
Server y complementan eficientemente situaciones como esta. Lo sé... es
que con otros lenguajes no se puede. Comprendo tu sorpresa..:))) Los de
VFP no los llames cursores para que no te confundas, digamosles tablas
temporales.

En sintesis, la carga agregada de tener que unir los datos en el cliente no
es relevante para un proceso eventual como una consolidación.

Sabes que en ADO.NET 2.0 no existen mas los cursores? te imaginas porque?
justamente para que los developer no hagan tu tecnica que es para nada
recomendada. Porque tener las cosas duplicadas si ya estan en un
repositorio?
Porque saturar la RED?


>
> Claro que sí porque la integridad referencial es dentro de las tablas de
> cada BD. Ahora bien, si es que hablas de tablas comunes a varias
> empresas, bueno ya eso es otra cosa pero, puedes tenerlas en la base de
> datos del sistema que seria otra o en su defecto copiar los datos a

medida

> que se modifiquen. Normalmente las tablas que se hacen comunes no son
tablas
> de operaciones, sino tablas maestras como de clientes, articulos, etc..
> Pero para tu caso, teniendo todo junto, me imagino que sería más
complicado
> hacer cada vez una excepción de no filtrar la empresa cuando se trate de
una
> tabla comun.

Si la de las mismas BDD ok pero las tablas compartidas no, por lo cual o
debes aplicar TR con los problemas de mantenimiento que lleva no. En sql2k
la forma natural de hacer Integridad referencial es por medio de Claves
Externas y no por TR

> Es claro.. Eso no se discute. Hablé de una manipulación local en

Visual

> Foxpro de datos devueltos desde el servidor SQL. Esta manipulación

aunque

> afecta el desempeño final para el usuario, no afecta el rendimiento del
> servidor que interfiera con los demás usuarios.

Seguro que no afecta el servidor? pone un contador de transferencias de

RED

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

de

un lado al otro por tu RED y seguramente si estas haciendo muchos SELECT *
FROM el servidor esta haciendo Table Scan y esto afecta enormemente el
rendimiento del servidor.

Lo afecta.. Pero no tanto como crees. Yo estoy seguro que muchos, no digo
que tu caso, de los que tienen todo junto en una BD multiempresa no se han
detenido a probar la otra forma simplemente porque los ERP's lo usan así.


Saludos, amigo.

Ricardo Passians

Cursores en VFP son realmente tablas. VFP tiene su propia base de datos.
Por tanto esos cursores a que me refiero no tienen nada que ver con los
cursores de SQL Server ni con los cursores de ADO.NET o los datasets de
Delphi.

Es la gran ventaja de VFP respecto a otros lenguajes, que puedes combinar
sus propias tablas con los resultados devueltos de un servidor SQL.



"Maxi" wrote in message
news:

ok Ricardo, no usas SP por lo que veo que estas accediendo a las tablas de
forma directa verdad? bueno aca vamos a seguir discutiendo porque para mi

no

es ideal que una sesion acceda a la tabla de forma directa.

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

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

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

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




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



"Ricardo Passians" escribió en el mensaje
news:
> >
> > A ver, vos me decis que por cada BDD armas los SP necesarios y ademas
> tenes
> > uno que consolida que recorre las BDD (como?) y que todo esto es mejor
que
> > poner todo junto?
> >
>
> Mala interpretacion. No tengo un SP de consolidación. Hago el proceso
> desde mi aplicación (el front-end) que es unir los resultados devueltos
por
> la llamada a los sp's de cada BD. Los SP's trabajan sobre la propia

BD

en
> que residen. El recorrido no lo hago en un SP, lo hago desde mi
aplicación,
> en ésta también se programa no ? :)
>
> >
> > A ver, no se cual es tu experiencia, pero yo suelo ser una persona que
me
> > gusta ver lo que hacen las grandes empresas y ver que puedo copiar y

que

> > cosa no :-p
> >
> >
> > Una de las cosas que aprendi en todo estos años, es que los ERP mas
> grandes
> > del planeta (conozco una instalacion SAP que superar los 5TB) tienen
todo
> en
> > una sola BDD (el multiempresa) y nunca dividen en varias BDD.
> >
>
> No lo discuto, esos ERPs son super aplicaciones con años de depuración y
> gran cantidad de personal de control de calidad. Pero para los que
tenemos
> pequeñas empresas y no más de 5 programadores, sólo digo que la
programación
> tiende a ser más compleja y propensa a errores por el simple hecho de
tener
> que filtrar cada query con la columna "empresa". Y si aparte de

empresa,

> ya tenemos una variable como "Division" o "Centro de Costo", solo hay

que

> imaginarse:)
>
> >
> > Esto basicamente por todo lo que comente antes y que vos bien

dijistes,

> > debes cambiar el SP de consolidacion y ademas tenes otros problemas

como

> por
> > ej:
>
> Error.. No hay un SP de consolidacion, como digo arriba. Consolido los
> resultados en la aplicación.
>
> >
> > La integridad Referencial.
> >
> > Esta ultima la debes armar con Trigger y no vas a poder usar FK.
> >
>
> Claro que sí porque la integridad referencial es dentro de las tablas de
> cada BD. Ahora bien, si es que hablas de tablas comunes a varias
> empresas, bueno ya eso es otra cosa pero, puedes tenerlas en la base de
> datos del sistema que seria otra o en su defecto copiar los datos a

medida

> que se modifiquen. Normalmente las tablas que se hacen comunes no son
tablas
> de operaciones, sino tablas maestras como de clientes, articulos, etc..
> Pero para tu caso, teniendo todo junto, me imagino que sería más
complicado
> hacer cada vez una excepción de no filtrar la empresa cuando se trate de
una
> tabla comun.
>
> >
> > Ahora bien, esto de dividir las cosas es una idea y practica de muchos
> > developer (sobre todo Fox) porque hay una cosa que es cierta:
> >
> > Fox - Access o cualquier bdd de este tipo trabajn muy pero muy

distinto

a
> > SQL - Oracle u DB2 por ej.
> >
>
> Es claro.. Eso no se discute. Hablé de una manipulación local en

Visual

> Foxpro de datos devueltos desde el servidor SQL. Esta manipulación

aunque

> afecta el desempeño final para el usuario, no afecta el rendimiento del
> servidor que interfiera con los demás usuarios.
>
> >
> > Entonces se aplican las viejas tecnicas en un motor como SQL, cuando
poner
> > una columna es algo muy simple de verdad y no se complica ninguna
consulta
> > te lo aseguro.
> >
>
> Bueno, cuestion de opinion para mi tener que agregar un AND en cada

WHERE

y
> cada JOIN para incluir la empresa me parece complicado y aumenta la
> posibilidad de errores, aunque entiendo que pueda ser lo ideal tenerlo
así.
>
> > Mira, el ERP que tenemos en la empresa tambien esta armado asi y no es
> SAP,
> > y tenemos mas de 10 empresas dentro y te digo que es algo simple y no
hay
> > ningun tipo de confusion :-)
> >
> >
> > Vuelvo a repetir, no veo ningun beneficio en dividir las empresas en

mas

> de
> > una BDD!!
>
> Bueno, amigo, aunque lo digas como si fuera una sentencia, la tuya es
> también una opinión subjetiva, igual que la mia. La respeto pero no la
> comparto.
>
> >podrias exponer vos que ventajas le ves a ese modelo? porque yo ya
> > expuse las desventajas y las ventajas del otro modelo :-)
> >
>
>
> La ventaja para mi es que programo la aplicación simplemente ignorando

el

> parámetro "empresa", desarrollando así consultas, búsquedas,
combinaciones,
> sp's, más sencillos que permitan mejor RAD y menos posibilidad de

cometer

> errores. Eso para mi es más que suficiente ventaja. Otra ventaja sería
> excluir la necesidad de índices sobre la columna "empresa" sobre todo en
> tablas de muchos registros, peor aún si ya existe otra variable como
> "division" o "centro de costo".
>
>



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

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

Vaya, un colega... Pensé que estaba peleando solo por aquí ... X-DDD

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

Muy cierto eso. Es una tendencia que hay de pensar primero en mejorar el
hardware cuando a veces con una mejor definición de índices por ejemplo se
pueden obtener mejoras considerables.