¿Para que sirven las relaciones en las bases de datos?

Iniciado por skan, 30 Octubre 2013, 21:55 PM

0 Miembros y 1 Visitante están viendo este tema.

skan

Buenas

Supongo que esta pregunta os parecerá un poco tonta pero...

Sé cual es la definición de relación, y hace tiempo me estudié la teoría de las BD, y se como se crean en MySQL y en alguna otra base de datos, pero...

Además de para comprobar la integridad referencial y para indicarle al usuario que existe una relación entre campos,  ¿Para qué se usan las relaciones en las bases de datos?

Por ejemplo para hacer JOINS no necesito relaciones, simplemente indicando los campos para la condición de igualdad ON, es suficiente.

¿Podríais darme algún ejemplo de uso de las relaciones, en el que sea necesario las relaciones?

Gracias

DanteInfernum

Que dos tablas estén relacionadas entre si significa que una de ellas tiene una clave foránea que referencia a la clave principal de la otra.

No creo que sirvan para algo más que para prevenir posibles errores de integridad referencial como bien dijiste.

Pero, como dice el dicho: ¡Más vale prevenir que curar!
Así que siempre es bueno usar relaciones.

skan

#2
Cita de: DanteInfernum en  2 Noviembre 2013, 00:53 AM
Que dos tablas estén relacionadas entre si significa que una de ellas tiene una clave foránea que referencia a la clave principal de la otra.

No creo que sirvan para algo más que para prevenir posibles errores de integridad referencial como bien dijiste.

Pero, como dice el dicho: ¡Más vale prevenir que curar!
Así que siempre es bueno usar relaciones.

OK, gracias.

Pregunté en otro foro y me trataron de burro por preguntarlo, me dijeron que debería estudiar.

De todos modos, ¿Podrías poner un ejemplo SQL simple de alguna operación que no se pueda hacer (o sí) según tenga definida una foreign key (o no)?

DanteInfernum

Considera las tablas:
Personas, Vehículos y Viviendas, todas ellas relacionadas con una tabla Seguros
(son los distintos tipos de seguros que ofrece la empresa)

Ahora tengo que crear un procedimiento que elimine un seguro determinado.

Gracias a que las tablas están relacionadas mediante foreign keys, lo que hice fue añadirles a cada foreign key la restricción ON DELETE CASCADE, la cual me asegura que al eliminar un registro de la tabla padre (seguros), se eliminarán automáticamente todos los registros relacionados en las tablas hijas (tipos de seguro).

El haber utilizado foreign keys me ahorró muchísimo tiempo. Ni sé cuantas vueltas habría tenido que dar para poder eliminar completamente un seguro de no ser por la restricción ON DELETE CASCADE propia de las foreign keys.


A lo que voy, siempre (al menos eso creo...) puedes trabajar sin utilizar ninguna foreign key, pero a la hora de andar haciendo actualizaciones, eliminando registros, etc., desearás haberlo hecho.


PD: En cuanto a las típicas respuestas de forero aburrido y prepotente, ya me he topado con esa clase de individuos. Dale la espalda a los soberbios, son estúpidos, pues no son capaces de comprender su propia ignorancia. No existe nadie en el mundo que "se las sepa todas", siempre nos va faltar algo por conocer, en todos los órdenes de la vida. Aparte que por algún lado se empieza; y haciendo preguntas es un muy buen comienzo.

A mi ya me han tratado de "jodido vago" y "parásito" en otro lado ;D
Las cosas que se pueden llegar a leer por acá son increíbles... jaja

skan

Cita de: DanteInfernum en  2 Noviembre 2013, 02:48 AM
Considera las tablas:
Personas, Vehículos y Viviendas, todas ellas relacionadas con una tabla Seguros
(son los distintos tipos de seguros que ofrece la empresa)

Ahora tengo que crear un procedimiento que elimine un seguro determinado.

Gracias a que las tablas están relacionadas mediante foreign keys, lo que hice fue añadirles a cada foreign key la restricción ON DELETE CASCADE, la cual me asegura que al eliminar un registro de la tabla padre (seguros), se eliminarán automáticamente todos los registros relacionados en las tablas hijas (tipos de seguro).

El haber utilizado foreign keys me ahorró muchísimo tiempo. Ni sé cuantas vueltas habría tenido que dar para poder eliminar completamente un seguro de no ser por la restricción ON DELETE CASCADE propia de las foreign keys.


A lo que voy, siempre (al menos eso creo...) puedes trabajar sin utilizar ninguna foreign key, pero a la hora de andar haciendo actualizaciones, eliminando registros, etc., desearás haberlo hecho.


PD: En cuanto a las típicas respuestas de forero aburrido y prepotente, ya me he topado con esa clase de individuos. Dale la espalda a los soberbios, son estúpidos, pues no son capaces de comprender su propia ignorancia. No existe nadie en el mundo que "se las sepa todas", siempre nos va faltar algo por conocer, en todos los órdenes de la vida. Aparte que por algún lado se empieza; y haciendo preguntas es un muy buen comienzo.

A mi ya me han tratado de "jodido vago" y "parásito" en otro lado ;D
Las cosas que se pueden llegar a leer por acá son increíbles... jaja

OK, ¿Y si usas el foreign key  pero sin "ON DELETE CASCADE"  (ni  ON UPDATE CASCADE) Entonces que efectos se observan?

DanteInfernum

Tendría que eliminar el seguro manualmente. Primero buscarlo en cada una de las tablas persona, vehículo y vivienda (ya que no conozco de antemano que tipo de seguro es), borrarlo de ahí, y luego eliminarlo de la tabla seguros. Habría que utilizar un montón de if (if seguro esta acá, borrarlo, si no, seguir buscando en otro lado...).

Imaginate todo el código que tendría que agregar si sigo añadiendo distintos tipos de seguro a la empresa.

Pero los efectos más que nada son esos, las foreign keys te previenen que no vayas a andar haciendo referencia a datos que no existen. Si querés eliminar un registro, antes vas a tener que eliminar todas las foreign keys que hacen referencia a él.

skan