sql y .net

Suerte, creo que es una decisión bastante mala. Desde luego que SQL es un
sistema menos escalable que librería en .NET, pero el riesgo de que los
desarrolladores empiezen a traerse trozos muy grande de la base de datos a
memoria para hacer operaciones es tan alto en esta arquitectura que propones
que seguramente acabareis teniendo serios problemas de rendimiento.
Sin ser catastrofista ni purista, creo que cada proyecto es un mundo, y que
cada arquitectura hay que decidirla en la fase de diseño tecnico de la
aplicación. Que se hagan o no determinadas acciones en un sitio o en otro
debería ser responsabilidad y decisión del Analista o Jefe de proyectos en
base al proyecto concreto, a las necesidades del cliente, al número de
usuarios esperado, a la formación que tenga el equipo de desarrollo, etc.
Andar poniendo reglas y que todo se haga bajo el mismo patrón es seguro
contraproducente. Como también lo es que no existan unas guias de referencia
para hacer las cosas. Creo que el analista, o jefe de proyectos, como el
profesor en la universidad, debería tener algo de 'libertad de cátedra' en
este sentido. Pero vamos, es mi opinión.


Saludos

Miguel Egea
Microsoft SQL-SERVER MVP
Brigada Anti-Cursores
"Elena" escribió en el mensaje
news:e$

Hola,
quería hacer una consulta sobre un tema que me preocupa.
En mi empresa se quiere cambiar la arquitectura, de manera que en la base

de

datos ya no se programe nada, es decir no se utilizarán procedimientos
almacenados y todo lo que se necesite programar se hará en el componente

en

.net. Quería saber vuestra opinión sobre si es más óptimo realizar la
programación en el componente y en la base de datos tener los objetos
básicos.

Un saludo

Bueno aca coincido con Miguel 100%, este tema me llevo horas de discusion
con varias personas que ahora quieren hacer N-capas y se olvidan de muchas
cosas.

Tu sistema sera muy lento si lo haces asi, a mi me gusta sacarle el 100% de
jugo al motor por muchas razones

Te recomiendo que mires esto de "Jimmy Nilson"

espero te sea util como me fue a mi a la hora de discutir este tema de forma
profesional

Bye


Más material del autor, en su web: http://www.jnsk.se
sus últimos artículos: http://www.jnsk.se/book/NewArticles.htm
su weblog (RSS): http://www.jnsk.se/weblog/rss.xml



Salu2
Maxi
Buenos Aires Argentina
Desarrollador Microsoft 3 Estrellas .NET
[Maxi_accotto[arroba]speedy[punto]com[punto]ar
MSN:


"Elena" escribió en el mensaje
news:e$

Hola,
quería hacer una consulta sobre un tema que me preocupa.
En mi empresa se quiere cambiar la arquitectura, de manera que en la base

de

datos ya no se programe nada, es decir no se utilizarán procedimientos
almacenados y todo lo que se necesite programar se hará en el componente

en

.net. Quería saber vuestra opinión sobre si es más óptimo realizar la
programación en el componente y en la base de datos tener los objetos
básicos.

Un saludo

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.593 / Virus Database: 376 - Release Date: 21/02/2004

Muchas gracias por tu opinión, me gustaría tener más puntos de vista sobre
esta problemática.
Entre ventajas que me han contado por las que se quiere realizar este cambio
sería la portabilidad de la base de datos de un sistema de gestión a otro,
ejemplo de SQL Server a Oracle; de manera que no habría que cambiar los
procedimientos almacenados. También me han dicho que en la actualidad se
tiende a hacer la programación en el componente; y quería saber si es
cierto.

"Miguel Egea" escribió en el mensaje
news:%

Suerte, creo que es una decisión bastante mala. Desde luego que SQL es un
sistema menos escalable que librería en .NET, pero el riesgo de que los
desarrolladores empiezen a traerse trozos muy grande de la base de datos a
memoria para hacer operaciones es tan alto en esta arquitectura que

propones

que seguramente acabareis teniendo serios problemas de rendimiento.
Sin ser catastrofista ni purista, creo que cada proyecto es un mundo, y

que

cada arquitectura hay que decidirla en la fase de diseño tecnico de la
aplicación. Que se hagan o no determinadas acciones en un sitio o en otro
debería ser responsabilidad y decisión del Analista o Jefe de proyectos en
base al proyecto concreto, a las necesidades del cliente, al número de
usuarios esperado, a la formación que tenga el equipo de desarrollo, etc.
Andar poniendo reglas y que todo se haga bajo el mismo patrón es seguro
contraproducente. Como también lo es que no existan unas guias de

referencia

para hacer las cosas. Creo que el analista, o jefe de proyectos, como el
profesor en la universidad, debería tener algo de 'libertad de cátedra' en
este sentido. Pero vamos, es mi opinión.


Saludos

Miguel Egea
Microsoft SQL-SERVER MVP
Brigada Anti-Cursores
"Elena" escribió en el mensaje
news:e$
> Hola,
> quería hacer una consulta sobre un tema que me preocupa.
> En mi empresa se quiere cambiar la arquitectura, de manera que en la

base

de
> datos ya no se programe nada, es decir no se utilizarán procedimientos
> almacenados y todo lo que se necesite programar se hará en el componente
en
> .net. Quería saber vuestra opinión sobre si es más óptimo realizar la
> programación en el componente y en la base de datos tener los objetos
> básicos.
>
> Un saludo
>
>

Ese tipo de decisiones solo lo habia visto en una empresa
que aún tenía indefinido el motor de base de datos con el
cual iba a estar en producción y que trataron de avanzar
la programación usando sentencias totalmente ANSI, pero
que al final de cuentas terminaron por tener problemas de
rendimiento que motivaron que utilizaran los stored
procedures. Lo que si he visto es que los procedimientos
almacenados se reduzcan al máximo sin nada de lógica y
solo operaciones contra la base de datos y que el control
de transacciones se realice en los componentes, en muchos
casos ha funcionado pero todo parte del diseño que se haga.

Saludos,
Ulises

Hola,
quería hacer una consulta sobre un tema que me preocupa.
En mi empresa se quiere cambiar la arquitectura, de

manera que en la base de

datos ya no se programe nada, es decir no se utilizarán

procedimientos

almacenados y todo lo que se necesite programar se hará

en el componente en

..net. Quería saber vuestra opinión sobre si es más

óptimo realizar la

programación en el componente y en la base de datos tener

los objetos

básicos.

Un saludo


.

Me voy a meter porque manejo un ERP que trabaja tanto en Oracle como en Sql
y DB2.

No es verdad eso, si quieres que tu sistema sea bueno y optimo deberiar
armar los Triggers,vistas para cada uno de tus motores.

Una muy buena tecnica es utilizar Stores entonces para cada motor tenes tu
Stores de por ej:

ABM Articulos
ABM Clientes

Etc.

Lo de programar todo en el componente tiene otros problemas como por ej
este:

Que pasa si un ñato pone un dato desde afuera? ojo con esto

Yo trabajo en .NET y deberian pensar las aplicaciones de otra forma, por ej:

Utilizar la capa de Presentacion esta bien - luego yo la de negocios la meto
toda en el motor (casi toda) con esto tengo una gran portabilidad aunque no
lo creas y mi sistema bien optimizado para cada Motor.

Un ejemplo de lo que puede pasar: Imaginate que cuando se ingresa un pedido
vos por regla de negocios armas un trigger y haces una accion X, bien esto
lo sacas de aca y lo mandas a un componente.
Ahora bien, como los sistemas hay que pensarlos bien Escalares (si es para
50 Usuarios pensalo para 250) aparece un Gte y dice:
Ahora hacen una migracion por ej y chau logica de negocios!!!


Los argumentos que te puedo dar son estos:

Tecnologia tenemos mucho, el tema es saber usarla lo mas efectiva posible y
una mala desicion en el comienzo de tu proyecto puede hacerlo fracazar
mucho!!!
el tiempo que inviertan en analizar Arquitectura es mas que bien invertido!!
pero bue es solo mi punto de vista nomas, cada cual sabe lo que hace y como
lo hace.

Bye



Salu2
Maxi
Buenos Aires Argentina
Desarrollador Microsoft 3 Estrellas .NET
[Maxi_accotto[arroba]speedy[punto]com[punto]ar
MSN:


"Elena" escribió en el mensaje
news:

Muchas gracias por tu opinión, me gustaría tener más puntos de vista sobre
esta problemática.
Entre ventajas que me han contado por las que se quiere realizar este

cambio

sería la portabilidad de la base de datos de un sistema de gestión a otro,
ejemplo de SQL Server a Oracle; de manera que no habría que cambiar los
procedimientos almacenados. También me han dicho que en la actualidad se
tiende a hacer la programación en el componente; y quería saber si es
cierto.

"Miguel Egea" escribió en el mensaje
news:%
> Suerte, creo que es una decisión bastante mala. Desde luego que SQL es

un

> sistema menos escalable que librería en .NET, pero el riesgo de que los
> desarrolladores empiezen a traerse trozos muy grande de la base de datos

a

> memoria para hacer operaciones es tan alto en esta arquitectura que
propones
> que seguramente acabareis teniendo serios problemas de rendimiento.
> Sin ser catastrofista ni purista, creo que cada proyecto es un mundo, y
que
> cada arquitectura hay que decidirla en la fase de diseño tecnico de la
> aplicación. Que se hagan o no determinadas acciones en un sitio o en

otro

> debería ser responsabilidad y decisión del Analista o Jefe de proyectos

en

> base al proyecto concreto, a las necesidades del cliente, al número de
> usuarios esperado, a la formación que tenga el equipo de desarrollo,

etc.

> Andar poniendo reglas y que todo se haga bajo el mismo patrón es seguro
> contraproducente. Como también lo es que no existan unas guias de
referencia
> para hacer las cosas. Creo que el analista, o jefe de proyectos, como el
> profesor en la universidad, debería tener algo de 'libertad de cátedra'

en

> este sentido. Pero vamos, es mi opinión.
>
>
> Saludos
>
> Miguel Egea
> Microsoft SQL-SERVER MVP
> Brigada Anti-Cursores
> "Elena" escribió en el mensaje
> news:e$
> > Hola,
> > quería hacer una consulta sobre un tema que me preocupa.
> > En mi empresa se quiere cambiar la arquitectura, de manera que en la
base
> de
> > datos ya no se programe nada, es decir no se utilizarán procedimientos
> > almacenados y todo lo que se necesite programar se hará en el

componente

> en
> > .net. Quería saber vuestra opinión sobre si es más óptimo realizar la
> > programación en el componente y en la base de datos tener los objetos
> > básicos.
> >
> > Un saludo
> >
> >
>
>

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.593 / Virus Database: 376 - Release Date: 21/02/2004