Re: Sistema multiempresa

18/10/2004 - 04:29 por MAXI | Informe spam
Hola, el tema es interesante de discutir :-)

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?

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.

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:

La integridad Referencial.

Esta ultima la debes armar con Trigger y no vas a poder usar FK.

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.

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.

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!! podrias exponer vos que ventajas le ves a ese modelo? porque yo ya
expuse las desventajas y las ventajas del otro modelo :-)






Maxi

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

Msn Messager: Maxi_adrogue@msn.com





Maxi

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

Msn Messager: Maxi_adrogue@msn.com

Preguntas similare

Leer las respuestas

#6 Daniel Durand
18/10/2004 - 16:02 | Informe spam
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
#7 Maxi
18/10/2004 - 17:59 | Informe spam
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
tráfico
Mostrar la cita
datos
Mostrar la cita
el
Mostrar la cita
distintas
Mostrar la cita
proceso
Mostrar la cita
BD
Mostrar la cita
acceda
Mostrar la cita
pasando
Mostrar la cita
y
Mostrar la cita
que
Mostrar la cita
aseguro
Mostrar la cita
porque?
Mostrar la cita
de
Mostrar la cita
de
Mostrar la cita
sql2k
Mostrar la cita
Visual
Mostrar la cita
*
Mostrar la cita
WHERE
Mostrar la cita
de
Mostrar la cita
otros
Mostrar la cita
ahora
Mostrar la cita
el
Mostrar la cita
sería
Mostrar la cita
en
Mostrar la cita
es
Mostrar la cita
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
#8 ulises
18/10/2004 - 18:24 | Informe spam
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
por un lado te
Mostrar la cita
lado por usar este
Mostrar la cita
aplicación. Por
Mostrar la cita
problemas de tráfico
Mostrar la cita
manipula los datos
Mostrar la cita
cliente, no estas
Mostrar la cita
cursores o como
Mostrar la cita
si yo desde mi
Mostrar la cita
por que no optar
Mostrar la cita
de los datos en el
Mostrar la cita
SP's, y por
Mostrar la cita
opciones estan
Mostrar la cita
tablas de distintas
Mostrar la cita
Hago el proceso
Mostrar la cita
resultados devueltos
Mostrar la cita
sobre la propia BD
Mostrar la cita
desde mi
Mostrar la cita
forma directa, con
Mostrar la cita
(sesion) no acceda
Mostrar la cita
SP y estas pasando
Mostrar la cita
RED con datos
Mostrar la cita
años de depuración y
Mostrar la cita
para los que
Mostrar la cita
digo que la
Mostrar la cita
simple hecho de
Mostrar la cita
aparte de
Mostrar la cita
Costo", solo hay que
Mostrar la cita
puedes copiar
Mostrar la cita
SQL-Server te aseguro
Mostrar la cita
tambien!! ahora si
Mostrar la cita
arriba. Consolido los
Mostrar la cita
otro (saturando
Mostrar la cita
imaginas porque?
Mostrar la cita
que es para nada
Mostrar la cita
estan en un
Mostrar la cita
de las tablas de
Mostrar la cita
comunes a varias
Mostrar la cita
tenerlas en la base de
Mostrar la cita
los datos a
Mostrar la cita
comunes no son
Mostrar la cita
articulos, etc..
Mostrar la cita
sería más
Mostrar la cita
cuando se trate de
Mostrar la cita
no, por lo cual o
Mostrar la cita
lleva no. En sql2k
Mostrar la cita
medio de Claves
Mostrar la cita
manipulación local en Visual
Mostrar la cita
manipulación
Mostrar la cita
rendimiento del
Mostrar la cita
transferencias de
Mostrar la cita
datos completos
Mostrar la cita
haciendo muchos SELECT *
Mostrar la cita
enormemente el
Mostrar la cita
AND en cada WHERE
Mostrar la cita
y aumenta la
Mostrar la cita
lo ideal tenerlo
Mostrar la cita
developer o no, si
Mostrar la cita
Datos Relacional)
Mostrar la cita
un gran cuello de
Mostrar la cita
que en una
Mostrar la cita
tengan BDD de otros
Mostrar la cita
servidor, vos que
Mostrar la cita
corporativa, ahora
Mostrar la cita
sentencia, la tuya es
Mostrar la cita
respeto pero no la
Mostrar la cita
que no es
Mostrar la cita
exponiendo :-)
Mostrar la cita
simplemente ignorando el
Mostrar la cita
búsquedas,
Mostrar la cita
posibilidad de
Mostrar la cita
Otra ventaja sería
Mostrar la cita
"empresa" sobre todo en
Mostrar la cita
variable como
Mostrar la cita
usaras SP que es
Mostrar la cita
"ventajas" no son
Mostrar la cita
el SP mientras
Mostrar la cita
razonamiento, pero como
Mostrar la cita
recomendadas de BDD (en
Mostrar la cita
la comodidad a
Mostrar la cita
01/10/2004
Mostrar la cita
#9 Daniel Durand
18/10/2004 - 18:37 | Informe spam
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
#10 Maxi
18/10/2004 - 19:34 | Informe spam
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
viajan
Mostrar la cita
servidores.
Mostrar la cita
se
Mostrar la cita
cambiar
Mostrar la cita
ideal
Mostrar la cita
llenes
Mostrar la cita
de
Mostrar la cita
aplicacion.
Mostrar la cita
ejecute
Mostrar la cita
si
Mostrar la cita
una
Mostrar la cita
buee
Mostrar la cita
mas
Mostrar la cita
si
Mostrar la cita
deban
Mostrar la cita
este
Mostrar la cita
Por
Mostrar la cita
mi
Mostrar la cita
optar
Mostrar la cita
en
Mostrar la cita
estan
Mostrar la cita
propia
Mostrar la cita
datos
Mostrar la cita
depuración
Mostrar la cita
de
Mostrar la cita
hay
Mostrar la cita
copiar
Mostrar la cita
los
Mostrar la cita
nada
Mostrar la cita
tablas
Mostrar la cita
son
Mostrar la cita
trate
Mostrar la cita
cual
Mostrar la cita
Claves
Mostrar la cita
de
Mostrar la cita
el
Mostrar la cita
tenerlo
Mostrar la cita
si
Mostrar la cita
cuello
Mostrar la cita
es
Mostrar la cita
la
Mostrar la cita
ignorando
Mostrar la cita
todo
Mostrar la cita
que
Mostrar la cita
mientras
Mostrar la cita
(en
Mostrar la cita
a
Mostrar la cita
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
Ads by Google
Search Busqueda sugerida