Ayuda relacionando productos.

05/12/2007 - 13:23 por Masta | Informe spam
Hola a todos.

Tengo la siguiente tabla:

RELACIONES
IDProducto int
IDProducto2 int

y tengo el siguiente Procedimiento Almacenado...

ALTER PROCEDURE [dbo].[ADMIN_Relacionar]
(
@id1 as int,
@id2 as int
)
AS
BEGIN

if (not exists(select * from new_relaciones where (idproducto=@id1 and
idproducto2=@id2) or (idproducto=@id2 and idproducto2=@id1))) and
(@id1<>@id2)
begin
insert into new_relaciones(idproducto,idproducto2)
values(@id1,@id2)
end
END

...Que lo que hace es relacionar dos productos que le pasamos,
comprobando antes que no exista la relación.

Ahora bien, quiero rizar el rizo y que, además de relacionar el "@id2"
al "@id", relacione también el "@id2" con todos los "id" que ya tiene
relacionados el "@id", pero por supuesto comprobando antes que no
exista ya la relación.

Ejemplo: Tenemos unos paraguas

1 - Azul
2 - Rojo
3 - Amarillo

En la tabla de relaciones tenemos que el Paraguas Azul (1) está
relacionado con el Rojo (2) y el Amarillo (3)
1 - 2
3 - 1

Ahora tenemos un nuevo paraguas
4 - Verde

Quiero que al relacionar el Verde (4) al paraguas Azul (1), éste
herede automáticamente sus relaciones, es decir, que relacione también
el Verde (4) con el Rojo (2) y el Amarillo (3).
Por supuesto entiendo que es tan sencillo como hacer un insert con un
select, pero es necesario comprobar antes que la relación que va a
crear automáticamente no exista ya en la tabla.

¿Alguna idea?

Espero haberme explicado bien, si no, decídmelo las dudas que os haya
dejado y intento explicároslo mejor.

Un saludo a todos

Preguntas similare

Leer las respuestas

#6 Leonardo Azpurua
07/12/2007 - 23:34 | Informe spam
"Carlos M. Calvelo" escribió en el mensaje
news:

Y ya no solo por reducir el volumen de datos registrados, sino
también por integridad. Por ejemplo, de la consulta no los va a
borrar nadie y de la tabla base puede que si.



Hola, Carlos:

Entiendo que en este caso particular nuestras opiniones no son tan
contrapuestas.

Pero de lo que expones me parece intuir que crees que existe una especie de
"seguro" contra los usuarios (o desarrolladores) tontos o mal intencionados.

El mismo idiota capaz de borrar el atributo de la tabla base puede borrar un
registro de la relación (haciéndolo desaparecer del conjunto de resultados
devueltos por la consulta), o incluso la vista o el SP que implementa la
consulta y mandar todo a tomapolculo.

Todos los intentos por defender nuestros diseños de los imbéciles lo único
que lograrán es "correr la arruga". Sólo si se diseñan unas políticas
óptimas para controlar lo que cada usuario puede o no puede hacer a nivel
del servidor, podemos estar relativamente seguros y diseñar sin la carga de
la paranoíca típica de nuestro oficio. Y aun así, puede que un idiota
"autorizado" (que varias veces he sido yo mismo: todos tenemos nuestros
"momentos") puede embarrarla espectacularmente.

Lo mejor es siempre lo más simple (y viceversa); siempre que se tenga clara
la distinción entre simplicidad y torpeza.


Salud!
Respuesta Responder a este mensaje
#7 Carlos M. Calvelo
08/12/2007 - 01:12 | Informe spam
Hola Leonardo,

On 7 dec, 23:34, "Leonardo Azpurua" <l e o n a r d o [arroba] m v p s
[punto] o r g> wrote:
"Carlos M. Calvelo" escribió en el mensajenews:

> Y ya no solo por reducir el volumen de datos registrados, sino
> también por integridad. Por ejemplo, de la consulta no los va a
> borrar nadie y de la tabla base puede que si.

Hola, Carlos:

Entiendo que en este caso particular nuestras opiniones no son tan
contrapuestas.

Pero de lo que expones me parece intuir que crees que existe una especie de
"seguro" contra los usuarios (o desarrolladores) tontos o mal intencionados.



No, no creo eso. Explico mas abajo, porque intuyes mal.


El mismo idiota capaz de borrar el atributo de la tabla base puede borrar un
registro de la relación (haciéndolo desaparecer del conjunto de resultados
devueltos por la consulta), o incluso la vista o el SP que implementa la
consulta y mandar todo a tomapolculo.



Me refería a que si en la operación de inserción se generan
registros derivados, entonces el borrar debería ser la inversa de
eso y no dejar borrar registros uno por uno.
Qué sentido tendría hacer la inserción de A que a su vez genera la
inserción de B para después poder borrar A o B, independientemente
uno del otro? (Pregunta retórica, pero a eso me refería)
Es una cuestión de simetría.



Todos los intentos por defender nuestros diseños de los imbéciles lo único
que lograrán es "correr la arruga". Sólo si se diseñan unas políticas
óptimas para controlar lo que cada usuario puede o no puede hacer a nivel
del servidor, podemos estar relativamente seguros y diseñar sin la carga de
la paranoíca típica de nuestro oficio. Y aun así, puede que un idiota
"autorizado" (que varias veces he sido yo mismo: todos tenemos nuestros
"momentos") puede embarrarla espectacularmente.



Si las restricciones de integridad y los autorizaciones de usuario
están bien definidos... bien embarrada estaría. :)

Como cuando a un base de datos se le dice que un artículo
tiene un precio de 6 Eur, cuando en realidad el precio es 5 Eur.
Una base de datos no puede defenderse de eso. Pero sí puede
tratar de garantizar la consistencia e integridad de los datos.

Saludos,
Carlos
email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una pregunta AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida