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