Respecto al punto 3b)
A mi se me ocurren 3 formas:
*Trigger
*CONSTRAINT -> CHECK
*SELF REFERENCING CONSTRAINT <-- Éste no lo mencionó nadie... Yo no sabía que existía hasta que lo leí de un resumen, página 36 y me parece la mejor, aunque nunca lo implementé así que no sé si funciona como yo creo.
http://www.utnianos.com.ar/foro/tema-apo...a-el-final
¿La solución que dicen de SP es hacer el INSERT/UPDATE sobre esta tabla siempre a través del SP? Pero sin el trigger o un constraint que me impide a mi hacer el insert/update "manualmente" y violar la propiedad que se intenta cumplir con el SP?
Cito solución con CHECK para una tabla y columnas genéricas:
drop table prueba1
create table prueba1
(col1 int not null,
col2 int not null,
CONSTRAINT c1 CHECK (col1<>col2)
)
insert prueba1 values (1,2) --OK
insert prueba1 values (1,1) --ERROR
Respecto al
3.a parece que la función funciona pero alguien por favor me podría explicar
para qué está la variable @max_grado? Desde mi punto de vista, esta variable es completamente innecesaria y podría
retornarse directamente la variable @grado, de éste modo, no sólo se escribe menos código (al no necesitar declarar la variable, por ejemplo) y utiliza menos espacio de RAM sino que además se elimina lógica:
Cita:IF(@grado > @max_grado)
BEGIN
SET @max_grado = @grado
END
El fragmento anterior no sería necesario.
EDIT: Volví a revisar la función y estoy 95% de que está bien (porque no me preocupo por la sintaxis ya que me aclaran que está bien). La variable @max_grado sí es necesaria, ya entendí la diferencia con retornar @grado. @grado me devuelve el grado de uno de los elementos componentes, pero si por ejemplo un producto está compuesto por dos elementos donde uno es de grado 2 y otro de grado 1 y el cursor me evalua primero el de grado 2 y dsp el de grado 1, entonces voy a devolver que mi producto es de grado 1+1 en lugar de 2+1 (que es la respuesta que quiero)