sql y .net

Hola Elena,

me gustaría que nos comentaras un poco más cómo se ha llegado a esa decisión en tu empresa; yo opino que la bd como una capa más de tu aplicación debe ser utilizada en función de las necesidades del proyecto; no se puede establecer una regla general para realizar o no realizar procesos de negocio en procedimientos almacenados, pero siempre depende del tipo de aplicación, usuarios, equipo de desarrollo, del entorno, arquitectura, etc.

Aunque supongo que ya habrás leido mucha literatura, te recomiendo las patterns & practices de MSDN:
Enterprise Solution Patterns Using Microsoft .NET
http://msdn.microsoft.com/architect...ml/Esp.asp

sería interesante conocer por qué se ha llegado a la decisión de no utilizar procedimientos almacenados ...

Gracias,

Eladio Rincón
Torrevieja - Alicante
MCAD, SQL Server MVP
http://www.siquelnet.com

"Comparte lo que sabes, aprende lo que no sepas." FGG

"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

¿Quién ha tenido esa idea?
Yo he visto trabajar a componentes en .NET que se han tenido que tirar abajo
y empezar de nuevo por falta de rendimiento, la mayoría del código de esos
componentes ha sido sustituido por un procedimiento almacenado, que ha
mejorado enormemente su rendimiento.

De todos modos, en tu empresa han pensado en la portabilidad del código,
pero ¿han pensado en la manera de realizar la conexión entre .NET y los
distintos gestores de bases de datos?


"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

Hola Elena:
Yo apoyo la opinion de Miguel de creer que es una mala desicion, aun
cuando tiene "buena intencion".
En un proyecto se deben mantener varios objetivos de diseno y rara vez
puede uno sacrificar todos los demas objetivoa para obtener un maximo de
alguno. Estoy seguro que parte de los objetivos de las aplicaciones que van
a desarrollar es seguridad, escalabilidad, desempeno, desarrollo rapido,
mantenimiento, etc. y no solo compatiblidad.
Te cuento una historia vieja, que te puede servir:
=No soy muy buen carpintero, me gusta la carpinteria pero no soy buen
carpintero. Los carpinteros usan muchas herramientas para su trabajo, tienen
varios tipos de martillos, varios tipos de serruchos, seguetas y otro
instumentos especiales. En mi caso, uso un martillo y un serrucho y con esto
casi hago todo.
CASI hago una silla, CASI hago una mesa, CASI hago un
= La moraleja es usa la herramienta adecuada, para el trabajo adecuado. El
servidor MS-SQL es un gestor de Base de Datos y el SQL es basicamente un
leguaje para recuperar y manipular los datos. Usa el SQL para lo que es
bueno. Usa VB.NET/C# .NET/C++.NET, etc, para lo que son buenos: crear
aplicaciones y componentes. Manten la logica y workflow de las aplicaciones
en componentes, y manten el acceso y manipulacion de los datos en el SQL.
Es una FALACIA pensar que porque no se escriben procedimientos
almacenados se estan independizando de la plataforma de hecho, suele ser al
contrario. Cuando los desarrolladores no usas procedimientos almacenados,
crean sentencias de SQL que incluyen en su codigo de VB/C#/C++.NET, y cuando
migran de SQL 2000 a la nueva version de SQL o a cualquier otra plataforma
lo que ocurre es que tienen que "bucear" el codigo de SQL entre los
componentes. Si quieres "independizar" tu aplicacion de la BD busca
desarrollar tus componente con un patron: "Phrase Book Design Pattern", que
mantiene el lenguaje separado. O haz lo que Visual Studio ayuda a
implementar que es crear TODO el codigo de SQL en Procedimientos
Almacenados, asi la aplicacion solo ve procedimientos si cambio la
plataforma, no debo cambiar el codigo en la aplicacion (excepto el proveedor
de Datos, Ora en vez de SQL y # en vez de @).
Si quieres mantener compatibilidad en el codigo de SQL, la solucion es
escribir codigo SQL que sea compatible entre diferentes plataformas (ANSI
SQL) y comentar y obligar a los desarrolladores a justificar las razones por
las cuales usan habilidades "especiales". Revisa la documentacion en linea
sobre:
SET FIPS_FLAGGER 'FULL'
Se requiere un arquitecto de sofware para tomar desciciones de como usar
cada una de las herramientas de desarrollo, la desicion de NO HAGAMOS
VENTANAS, SOLO PUERTAS PORQUE LAS PUERTAS SON MEJORES QUE LAS VENTANAS, no
es muy razonable.


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.
Elena escribio:

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

jeje muy bueno lo suyo Señor!! creo que ha puesto la realidad arriba de la
mesa y de forma muy simple :-D


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


"Javier Loria" escribió en el mensaje
news:%

Hola Elena:
Yo apoyo la opinion de Miguel de creer que es una mala desicion, aun
cuando tiene "buena intencion".
En un proyecto se deben mantener varios objetivos de diseno y rara vez
puede uno sacrificar todos los demas objetivoa para obtener un maximo de
alguno. Estoy seguro que parte de los objetivos de las aplicaciones que

van

a desarrollar es seguridad, escalabilidad, desempeno, desarrollo rapido,
mantenimiento, etc. y no solo compatiblidad.
Te cuento una historia vieja, que te puede servir:
=> No soy muy buen carpintero, me gusta la carpinteria pero no soy buen
carpintero. Los carpinteros usan muchas herramientas para su trabajo,

tienen

varios tipos de martillos, varios tipos de serruchos, seguetas y otro
instumentos especiales. En mi caso, uso un martillo y un serrucho y con

esto

casi hago todo.
CASI hago una silla, CASI hago una mesa, CASI hago un
=> La moraleja es usa la herramienta adecuada, para el trabajo adecuado.

El

servidor MS-SQL es un gestor de Base de Datos y el SQL es basicamente un
leguaje para recuperar y manipular los datos. Usa el SQL para lo que es
bueno. Usa VB.NET/C# .NET/C++.NET, etc, para lo que son buenos: crear
aplicaciones y componentes. Manten la logica y workflow de las

aplicaciones

en componentes, y manten el acceso y manipulacion de los datos en el SQL.
Es una FALACIA pensar que porque no se escriben procedimientos
almacenados se estan independizando de la plataforma de hecho, suele ser

al

contrario. Cuando los desarrolladores no usas procedimientos almacenados,
crean sentencias de SQL que incluyen en su codigo de VB/C#/C++.NET, y

cuando

migran de SQL 2000 a la nueva version de SQL o a cualquier otra plataforma
lo que ocurre es que tienen que "bucear" el codigo de SQL entre los
componentes. Si quieres "independizar" tu aplicacion de la BD busca
desarrollar tus componente con un patron: "Phrase Book Design Pattern",

que

mantiene el lenguaje separado. O haz lo que Visual Studio ayuda a
implementar que es crear TODO el codigo de SQL en Procedimientos
Almacenados, asi la aplicacion solo ve procedimientos si cambio la
plataforma, no debo cambiar el codigo en la aplicacion (excepto el

proveedor

de Datos, Ora en vez de SQL y # en vez de @).
Si quieres mantener compatibilidad en el codigo de SQL, la solucion es
escribir codigo SQL que sea compatible entre diferentes plataformas (ANSI
SQL) y comentar y obligar a los desarrolladores a justificar las razones

por

las cuales usan habilidades "especiales". Revisa la documentacion en linea
sobre:
SET FIPS_FLAGGER 'FULL'
Se requiere un arquitecto de sofware para tomar desciciones de como

usar

cada una de las herramientas de desarrollo, la desicion de NO HAGAMOS
VENTANAS, SOLO PUERTAS PORQUE LAS PUERTAS SON MEJORES QUE LAS VENTANAS, no
es muy razonable.


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.
Elena escribio:
> 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