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

#11 Daniel Durand
18/10/2004 - 19:45 | Informe spam
Un gusto

Saludos

"Maxi" wrote in message
news:
Mostrar la cita
#12 Ricardo Passians
19/10/2004 - 00:47 | Informe spam
Mostrar la cita
el
Mostrar la cita
a
Mostrar la cita
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... :)))

Mostrar la cita
empresa,
Mostrar la cita
que
Mostrar la cita
todo
Mostrar la cita
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.


Mostrar la cita
medida
Mostrar la cita
Visual
Mostrar la cita
aunque
Mostrar la cita
RED
Mostrar la cita
de
Mostrar la cita
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
#13 Ricardo Passians
19/10/2004 - 00:49 | Informe spam
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:
Mostrar la cita
no
Mostrar la cita
BD
Mostrar la cita
que
Mostrar la cita
empresa,
Mostrar la cita
que
Mostrar la cita
dijistes,
Mostrar la cita
como
Mostrar la cita
medida
Mostrar la cita
distinto
Mostrar la cita
Visual
Mostrar la cita
aunque
Mostrar la cita
WHERE
Mostrar la cita
mas
Mostrar la cita
el
Mostrar la cita
cometer
Mostrar la cita
#14 Ricardo Passians
19/10/2004 - 00:51 | Informe spam
Mostrar la cita
Vaya, un colega... Pensé que estaba peleando solo por aquí ... X-DDD
#15 Ricardo Passians
19/10/2004 - 00:54 | Informe spam
Mostrar la cita
dar
Mostrar la cita
le
Mostrar la cita
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.
Ads by Google
Search Busqueda sugerida