Stored Procedures are bad?

Hola Leonardo,

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

"Eduardo" escribió en el mensajenews:%

>> 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.

:-)
O un rallo en el RS232 del sistema.

O el nombre del SP o el número, orden y tipos de parámetros.
O el tipo, nombre y número de columnas retornadas.
O los derechos de ejecución, o ... pffff que sé yo...

Vamos la interfaz, lo mismo que para las tablas y las vistas.
Ninguna ventaja aquí para los SP.

Saludos,
Carlos

Mostrar la cita

O un rallo ...

:o Valla fayo! :-)

Eso... se llama "desnormalizar".

http://www3.uji.es/~mmarques/f47/apun/node97.html

No se pueden establecer una serie de reglas que determinen cuándo
desnormalizar relaciones, pero hay algunas situaciones muy comunes en donde
puede considerarse esta posibilidad:

a.. Combinar relaciones de uno a uno. Cuando hay relaciones (tablas)
involucradas en relaciones de uno a uno, se accede a ellas de manera
conjunta con frecuencia y casi no se les accede separadamente, se pueden
combinar en una sola relación (tabla).

b.. Duplicar atributos no clave en relaciones de uno a muchos para reducir
los joins. Para evitar operaciones de join, se pueden incluir atributos de
la relación (tabla) padre en la relación (tabla) hijo de las relaciones de
uno a muchos.

c.. Tablas de referencia. Las tablas de referencia ( lookup) son listas de
valores, cada uno de los cuales tiene un código. Por ejemplo puede haber una
tabla de referencia para los tipos de inmueble, con las descripciones de
estos tipos y un código asociado. Este tipo de tablas son un caso de
relación de uno a muchos. En la relación INMUEBLE habrá una clave ajena a
esta tabla para indicar el tipo de inmueble. De este modo, es muy fácil
validar los datos, además de que se ahorra espacio escribiendo sólo el
código y no la descripción para cada inmueble, además de ahorrar tiempo
cuando se actualizan las descripciones. Si las tablas de referencia se
utilizan a menudo en consultas críticas, se puede considerar la introducción
de la descripción junto con el código en la relación (tabla) hijo,
manteniendo la tabla de referencia para validación de datos.

d.. Duplicar claves ajenas en relaciones de uno a muchos para reducir los
joins. Para evitar operaciones de join, se pueden incluir claves ajenas de
una relación (tabla) en otra relación (tabla) con la que se relaciona (habrá
que tener en cuenta ciertas restricciones).

e.. Duplicar atributos en relaciones de muchos a muchos para reducir los
joins. Durante el diseño lógico se eliminan las relaciones de muchos a
muchos introduciendo dos relaciones de uno a muchos. Esto hace que aparezca
una nueva relación (tabla) intermedia, de modo que si se quiere obtener la
información de la relación de muchos a muchos, se tiene que realizar el join
de tres relaciones (tablas). Para evitar algunos de estos joins se pueden
incluir algunos de los atributos de las relaciones (tablas) originales en la
relación (tabla) intermedia.

f.. Introducir grupos repetitivos. Los grupos repetitivos se eliminan en
el primer paso de la normalización para conseguir la primera forma normal.
Estos grupos se eliminan introduciendo una nueva relación (tabla), generando
una relación de uno a muchos. A veces, puede ser conveniente reintroducir
los grupos repetitivos para mejorar las prestaciones.

Y eso es un semestre de ingenieria :D


saludos,


Antonio Ortiz
asesor en sistemas
ant(a)aortiz.net
www.aortiz.net
www.progvisual.com





"Alfredo Novoa" escribió en el mensaje
news:9njaw5r9g9bg.wm6gxyrf4thc$
Mostrar la cita

Hola Antonio,

El Sun, 25 May 2008 10:38:13 -0600, Antonio Ortiz escribió:

Mostrar la cita

muy bien, para estas pocas 'excepciones', vale la pena 'desnormalizar'

Me he perdido. ¿Que tiene que ver "desnormalizar" con lo que ha dicho
Miguel?


Saludos
Alfredo

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

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. :)

No lo sé. En mi caso, soy mejor previendo las necesidades imprevisibles de
las aplicaciones que cruzando calles :)

Evidentemente, un cambio en la interfaz de *cualquier cosa* (los parámetros
de un SP, por ejemplo) implica *notificarle* el cambio a todos los usuarios
de esa cosa (modificar el codigo fuente, recompilarlo y redistribuirlo), so
pena de que la relación deje de funcionar.

Pero no me refería a eso. Me refería a un cambio en la conducta interna de
un procedimiento: si está *fuera* del código compilado de la aplicación (por
ejemplo, en la BD) es más fácil cambiarlo que si está implementado en el
código fuente de la aplicación, compilado y guardado en X:\Archivos de
Programa de una cantidad de equipos.

Los cambios de implementación tienden a ser mucho más frecuentes que los
cambios de interfaz.


Salud!

On Sun, 25 May 2008 23:08:43 -0600, "Antonio Ortiz"
wrote:

Mostrar la cita

Eso... se llama "desnormalizar".

No, no lo has entendido.

Mostrar la cita

http://www3.uji.es/~mmarques/f47/apun/node97.html

No se pueden establecer una serie de reglas que determinen cuándo
desnormalizar relaciones, pero hay algunas situaciones muy comunes en donde
puede considerarse esta posibilidad:

a.. Combinar relaciones de uno a uno. Cuando hay relaciones (tablas)
involucradas en relaciones de uno a uno, se accede a ellas de manera
conjunta con frecuencia y casi no se les accede separadamente, se pueden
combinar en una sola relación (tabla).

Pero Miguel te estaba hablando de dividir una tabla en dos. En todo
caso eso sería normalizar.


Saludos
Alfredo