Stored Procedures are bad?

Si pablo, pero no solo te comente temas de migraciones, cuando haces un
laburpo de tunnig pasa lo mismo, cuando haces un QA idem :-)


Microsoft MVP SQLServer
www.sqltotalconsulting.com
-

"Pablo Roca" escribió en el mensaje de
noticias:ueT$
Mostrar la cita

Hola Maxi,

Bueno, ahi te doy la razón.

Aunque esas migraciones no serán muy habituales (en un cliente final, que
es mi caso).

Pero tambien con un poco de buenas prácticas en nuestra aplicación una
migración similar será tambien mucho mas fácil que no tenerlas.


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com

Hola Leonardo,

On 25 mei, 19:52, "Leonardo Azpurua" <l e o n a r d o [arroba] m v p s
[punto] o r g> wrote:
Mostrar la cita

"Antonio Ortiz" escribió en el mensajenews:%23N%

> Un interesante articulo, lo expongo para enriquecer el tema sin afan de
> defender tal o cual posicion. Lo ironico es que el autor del articulo es
> el mismo que creo la herramienta LLBLGen, que permite generar codigo para
> SP y clases .Net para la capa de datos.

Hola,

Frans omite un argumento que habría que tomar en cuenta, y que es MUY
importante desde el punto de vista del desarrollador de aplicaciones.

Los SP te permiten tener (parte de) la lógica de tu aplicación fuera del
programa compilado.

Yo suelo decir que los SP son 'pequeñas' aplicaciones que van con
la base de datos. Son específicos a una aplicación o grupo de
aplicaciones y no tienen nada que ver con el esquema lógico de la
base de datos, que está ahí para todas las aplicaciones; las
existentes y las que vengan.


Mostrar la cita

Si tienes un procedimiento que produce determinados
efectos, y en un momento dado a un cliente se le mete en la cabeza que no
quiere que tal efecto se produzca, o se produzca de otra manera, o que se
produzca un efecto adicional, te bastará con modificar el SP en la BD del
cliente, sin tocar tu código fuente, y sin cambiarle nada a nadie más.

Pero de ahí a la opinión casi religiosa de que hay que escribir un SP hasta
para la consulta más trivial, hay una gran diferencia.

Claro!

El esquema lógico que presenta los datos en forma de tablas es,
junto con un lenguaje como SQL, la interfaz por excelencia al mundo
exterior; si fuera necesario, por medio de un subesquema (vista
externa).

Una cosa es diseñar una base de datos y otra muy distinta meter
aplicaciones en la base de datos y no dar acceso al esquema lógico.
Eso es encapsular una base de datos. Aplicaciones nuevas con
necesidades que no pudieron ser previsas, que se las arreglen como
puedan entonces. Además aplicaciones vienen y van, pero los datos...

Pero no hay nada de malo en darle a la base de datos un poco del
trabajo que le corresponde lógicamente a las aplicaciones por
razones muy diversas, como las que tu explicas arriba. En algunos
casos también se podrán conseguir ese efecto con triggers.
Otras tareas son solo consecuencia de que una aplicación así lo
desea 'ahora' y otras de que simplemente son las 4:00 de la mañana
y es hora de hacerlo, etc, etc.

No se es menos aplicación por ir por la vida como SP en una base de
datos, ni se es más base de datos por estar encapsulada detrás de
una biblioteca de procedimientos. :-)

Saludos,
Carlos

Hola Antonio,

On 25 mei, 17:29, "Antonio Ortiz" wrote:
Mostrar la cita

Pues hasta ahora yo he creado y mantenido aplicaciones con bases de datos
pequeñas (hasta 1 gb) muy eficientemente con MSDE 1.0, MSDE 2000 & SQL
Server 2005 Express, donde todas mis consultas son codigo dinamico, y con un
resultado muy optimo en rendimiento he de decir. En ocasiones cerca de 2
decenas de usuarios se han conectado a un 'servidor' Clone AMD XP 2400 que
incluso hace de servidor de camaras, grabando lo de 4 camaras en otro disco
duro. Y uno o dos usuarios via internet (no web). Y debo decir que de estas
aplicaciones he distribuido y se encuentran trabajando mas de 1 millar sin
problemas.

No dudo de que funcione. Mi rechazo tiene mas que ver con lo que yo
pienso que tiene que ser una base de datos, una aplicación, cuales
son sus responsabilidades y lugar en un sistema de información y
como se tienen que comunicar. Y con el 'fallo' de este tipo
de herramientas en equiparar un tabla a una clase (tipo).

Claro que todos estos temas están interrelacionados pero no me
parece el tema de este hilo.


Mostrar la cita

Sin embargo esto fue asi debido a mi poco dominio de SPs, ahora estoy
encaminado a utilizar mas SP's. Sin debatir argumentos a favor o en contra,
mi percepcion es que es una buena practica usar SP's, punto. Aunque eso no
me impide analizar otras opiniones. 'Lo de cesar a cesar...'.

:D

Como has podido ver, hay consejos para todos los gustos.
Sírvase usted. :-)

Saludos,
Carlos

"Eduardo" escribió en el mensaje
news:%
Mostrar la cita

Mostrar la cita

produzca un efecto adicional, te bastará con modificar el SP en la BD del
cliente, sin tocar tu código fuente, y sin cambiarle nada a nadie más.

Siempre que no cambien los parámetros del SP.

O que no te arrolle una bicicleta de camino a la oficina del cliente.

Salud!

Mostrar la cita

Mostrar la cita

Mostrar la cita

cliente, sin tocar tu código fuente, y sin cambiarle nada a nadie más.

Siempre que no cambien los parámetros del SP.

O que no te arrolle una bicicleta de camino a la oficina del cliente.

Seguro que lo primero es mas probable que lo segundo. :)