MySQL - Es necesario definir las relaciones entre tablas (PK->FK)?

   
Vista:

Es necesario definir las relaciones entre tablas (PK->FK)?

Publicado por Rolando (10 intervenciones) el 13/05/2015 14:37:53
Siempre he tenido esa duda... La declaración de las relaciones entre las tablas de una base de datos ayuda en algo en las consultas?, Soy nuevo en esto, pero quiero saber por ejemplo para una consulta:

SELECT u.nombre,
u.apellido,
d.montoTotal
FROM usuario u,
deuda d
WHERE d.usu_id = u.usu_id
AND u.usu_id = 178

Cual sería la diferencia de hacerla en una base donde no están descritas las relaciones en la construcción de las tablas y una donde si las tenga?

Y el uso de este tipo de relación por consulta y el uso de * JOIN, también afecta al tiempo de respuesta?

Espero sus comentarios, Saludos y gracias
-- ROLA
Valora esta pregunta
Me gusta: Está pregunta es útil y esta claraNo me gusta: Está pregunta no esta clara o no es útil
0
Responder
Imágen de perfil de xve

Es necesario definir las relaciones entre tablas (PK->FK)?

Publicado por xve (899 intervenciones) el 13/05/2015 19:00:05
Hola Rolando, hasta donde yo se, el funcionamiento es el mismo en cuanto a las consultas... lo bueno que tienen las realizaciones, es que puedes indicar que hacer con la relación cuando se actualice o elimine el registro.... es muy común, indicar que se eliminen las relaciones al eliminar un registro dado.

No se si me he sabido explicar... coméntanos, ok?
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Es necesario definir las relaciones entre tablas (PK->FK)?

Publicado por Rolando (10 intervenciones) el 13/05/2015 20:46:56
Entiendo que te refieres a la eliminación en cascada, pero eso lo hacen los triggers asociados a un eveto delete o update?? o lo tengo que hacer manualmente por cada tabla que se relaciones con ese PK?

Por ejemplo, si elimino al usuario (como en el ejemplo anterior), se eliminarióa automáticamente la deuda? o tengo que escribir el código para que lo haga?

Gracias por tu respuesta, se entiende muy bien!

-- ROLA
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Es necesario definir las relaciones entre tablas (PK->FK)?

Publicado por SuperIndio (35 intervenciones) el 14/05/2015 16:17:58
No señor no es necesario... a menos que tengas bien definido por algun proceso o evento que vas a ejecutar una operacion del tipo DELETE por cascada... etc etc etc.. cuanto menos referencias, constraints, dependencias etc etc
sera mas facil entender y MIGRAR a cualquier base de datos.... o cualquiera que agarre el SQL DDL va a entender con rapidez el esquema....
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Es necesario definir las relaciones entre tablas (PK->FK)?

Publicado por Rolando (10 intervenciones) el 14/05/2015 16:23:04
Era lo que me suponía, las relaciones puedes ser por medio de código al momento de consultar/modificar los datos, no es necesario crearlas en la base de datos... no facilita ni mejora, ni ayuda en nada... quería confirmar eso.

Saludos y gracias.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Es necesario definir las relaciones entre tablas (PK->FK)?

Publicado por leonardo_josue (81 intervenciones) el 14/05/2015 17:38:24
Hola Ronalndo:

Mucho ojo, tú último comentario en realidad creo que está mal enfocado

1
no facilita ni mejora, ni ayuda en nada... quería confirmar eso.

Desde mi punto te vista el uso de FK es todo lo contrario, es decir, facilita, mejora y ayuda bastante en el concepto de una BD's.

En primer lugar, no hay que perder de vista que el concepto de FK o llaves foráneas está directamente relacionado con el concepto de INTEGRIDAD REFERENCIAL, es decir, cuando la información de una tabla ESTÁ RELACIONADA CON LA INFORMACIÓN DE OTRA TABLA... el caso típico es el de FACTURAS-DETALLES.

Una factura puede tener N detalles de Factura y viceversa, varios detalles de facturas DEBEN estar asociados a una factura. El concepto de relaciones es la base de todo el modelo ENTIDAD-RELACION, sin las llaves foráneas entonces este modelo simplemente no serviría de nada.

Alguna vez uno de mis maestros comentó que una BD's sin FK es simplemente un montón de basura y a lo largo de mi experiencia en BD's me he dado cuenta de la razón que tenía. Pero daré mis argumentos para decir que estás equivocado:

1. Las FK FACILITAN el trabajo de los DBA's y de los Programadores. Cuando tienes un modelo E-R, si no haces uso de llaves foráneas entonces el programador y/o el DBA DEBERÁ SER EL ENCARGADO DE MANTENER LA INTEGRIDAD REFERENCIAL. Tal como lo comentas, las relaciones pueden ser por medio de código, pero esto implicaría entonces que tienes que programar los TRIGGER's o artefactos de BD's necesarios para mantener la información actualizada en todo momento.

Tal como lo comenta SuperIndio, con FK NO ES NECESARIO IMPLEMENTAR NINGUNA ACCIONA ADICIONAL PARA MANETENER LA INFORMACIÓN INTEGRAL. Si defines una eliminación tipo CASCADA, al eliminar por ejemplo una FACTURA, el DBMS automáticamente eliminará todos los detalles asociados a esa factura, sin necesidad de el programador o el DBA tenga que hacer un delete adicional. Si por el contrario eliges una ELIMINACION RESTRINGIDA, entonces si un programador por error u omisión trata de eliminar una FACTURA que tenga asociados detalles, el DBMS automáticamente impedirá esta eliminación, notificando que hay información asociada a la factura.

2. Las FK Mejoran el entendimiento del Modelo E-R, sí tú creaste una BD's, es posible que tengas el conocimiento total del modelo, y sepas perfectamente de que trata cada tabla y cómo están relacionadas estas, sin embargo, cuanto trabajas con una BD's ajena, es posible que el entendimiento no sea tan simple. Cuando defines una FK desde la BD's, cualquier usuario puede saber en cualquier momento cómo están relacionadas estas tablas y cómo podría afectar un cambio al resto del modelo. Es decir, la BD's se "autodocumenta", bien podrías prescindir de un modelo "gráfico" de tu BD's y construirlo a partir de los metadatos de la BD´s.

3. Las FK ayudan a no olvidar u obviar detalles. Tiene un poco que ver con el punto anterior. Suele suceder que mientras trabajamos con un proyecto sabemos perfectamente todo lo que se hace y para qué se hace, sin embargo esto suele cambiar con el tiempo. Si no documentas un proceso sólo Dios y tú saben qué es lo que estás haciendo, unos meses después sólo Dios lo sabrá, pues ni tu mismo recordaras todos los detalles.

No sé por qué razón querías "confirmar" que las FK no sirven para nada, quizás valga la pena que expongas tus puntos de vista.

Saludos
Leo.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Es necesario definir las relaciones entre tablas (PK->FK)?

Publicado por Rolando (10 intervenciones) el 14/05/2015 17:52:44
Hola Leonardo...

Me explico mejor, entiendo todo lo que dices, en teoría y facilidad de entendimiento, siempre he trabajado con bases de datos relacionadas, por que si no, son sólo tablas de datos. Tengo claro lo de la eliminación en CASCADA y lo visualmente ordenado y claro que queda un MER.

Ahora voy a lo netamente práctico:
1.- Si yo tengo 2 tablas, sin relaciones en su definición ( como el ejemplo que di inicialmente). Le hago una consulta relacionada, el resultado en tiempo es el mismo que si están relacionadas.

2.- Si bien es cierto la eliminación en cascada premite eliminar el dato maestro y lo que tenga relacionado (por ejemplo al eliminar un usuario, se eliminarían todas sus deudas). Es también cierto que esta eliminación la tengo que programar si o si. Quizás hay que hacerlo sólo una vez como un trigger y decirle "si se elimina algo de esta tabla, elimine también todos los datos de esta otra tabla que coisidan con el ID eliminado", pero este proceso también se puede hacer por medio del lenguaje de programación que estés usando creando un evento en un objeto y diciéndole que si se ejecuta la función de eliminación, luego vaya a eliminar de la otra tabla lo que necesites...

En resumen, la velocidad no se ve afectada por tener o no un modelo de entidades relacionadas, sino que más bien es la integridad la que debes cuidar, pero no cambia en su velocidad si lo haces desde la base de datos o desde el lenguaje con el que la vayas a manejar.

Si estoy 100% de acuerdo contigo, que eso de la "autodocumentación" es clave en una base datos, y un MER lo deja claro por si sólo, en eso no tengo nada que decir, pero me refiero a lo práctico.

Gracias por tu respuesta Leo, saludos!
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Es necesario definir las relaciones entre tablas (PK->FK)?

Publicado por leonardo_josue (81 intervenciones) el 14/05/2015 18:37:18
Hola de nuevo Rolando:

Te comento lo siguiente:

1
2
1.- Si yo tengo 2 tablas, sin relaciones en su definición ( como el ejemplo que di inicialmente).
Le hago una consulta relacionada, el resultado en tiempo es el mismo que si están relacionadas.

Esto no necesariamente es cierto, me explico. Cuando hablamos del concepto de "velocidad" hay variables que no debemos perder de vista, como el tamaño de las tablas, el tipo de campos que son llaves, el número de tablas que están involucrados, el tipo de condiciones que estás armando en tu condición etc.

TODOS los DBMS's tienen algoritmos optimizados para el uso de índices y llaves, esto implicaría entonces que cualquier consulta en donde se involucren llaves e índices "deberá" ser más rápida que una que no lo sea. ¿Cierto?... En la mayoría de los casos podría asegurar que sí, es más, hablando de lo que preguntabas en tu primer pregunta, en la práctica es más rápido hacer JOIN's que hacer uniones explicitas, es decir:

es mejor poner esto

1
2
3
SELECT T1.campo, T2.campo
FROM tabla1 T1
INNER JOIN tabla2 T2 ON T1.campo = T2.campo

que hacer esto:

1
2
3
SELECT T1.campo, T2.campo
FROM tabla1 T1, tabla2 T2
WHERE T1.campo = T2.campo

y cuando te digo que es cierto, es cierto... igual con MySQL estás diferencias no son perceptibles, pero he tenido la oportunidad de trabajar con otras BD's como PostgreSQL, SQL Server, Firebird, Oracle, etc. y en algunos casos las diferencias pueden ser incluso de varios minutos (podrás imaginarte entonces el tamaño de nuestras consultas :S)

Insisto, cuando hablamos de pocas tablas o pocos registros, las diferencias pueden ser insignificantes, pero cuando hablamos de volumen pueden ser considerables. Entonces, si esto es verdad ¿deberíamos utilizar siempre los indices y las llaves foráneas? no necesariamente... (diablos, me estoy contradiciendo entonces o_O)

En algunos casos por ejemplo, cuando hablas de millones de registros colocar un indice puede resultar no tan benéfico. El uso por ejemplo de campos tipo VARCHAR en lugar de campos numéricos TAMBIÉN AFECTA EL TIEMPO DE RESPUESTA, sin que esto tenga necesariamente qué ver con que sean indices o llaves. Cuando se hacen BULK INSERT's o inserciones masivas, tampoco es recomendable utilizar campos llaves o indices, pues hace el proceso más lento...

Ahora bien, también comentas esto:

1
2
3
4
5
Es también cierto que esta eliminación la tengo que programar si o si. Quizás hay que hacerlo sólo una vez
como un trigger y decirle "si se elimina algo de esta tabla, elimine también todos los datos de esta otra tabla que
coisidan con el ID eliminado", pero este proceso también se puede hacer por medio del lenguaje de programación
que estés usando creando un evento en un objeto y diciéndole que si se ejecuta la función de eliminación, luego vaya
a eliminar de la otra tabla lo que necesites...

Creo que no ha quedado claro, que si lo haces desde la BD's NO TIENES QUE PROGRAMAR NADA ADICIONAL, Si defines una llave foránea TU NO PROGRAMAS UN TRIGGER QUE HAGA LA ELIMINACIÓN... esto lo hace la BD's de manera automática.

Mucho ojo, el que puedas hacer una acción de BD's desde un lenguaje de programación NO IMPLICA QUE DEBAS HACERLO O SEA LO MEJOR.

Efectivamente, coincido contigo en que puedes implementar mediante cualquier lenguaje de programación el proceso de eliminación en cascada, indicando un evento para cualquier objeto, pero te apuesto mi desayuno a que este SIEMPRE SERÁ MAS LENTO QUE HACERLO DIRECTAMENTE EN LA BD'S. Puede que la diferencia sea mínima, pero será diferencia al fin.

No sé con qué lenguaje de programación estés trabajando, pero sea cual sea, lo más probable es que estés trabajando con un Modelo-Vista-Controlador... ¿cuál es precisamente el objetivo de esta forma de programa? pues el dar independencia a cada una de las capas que conforman el proyecto. El modelo de BD's deberá ser lo más independiente de la lógica de negocio.

Supongamos que trabajas con JAVA e implementas la eliminación con una clase la cual detecta que cuando se elimine algún usuario entonces automáticamente se elimine la deuda asociada al usuario, todo funciona perfecto y no hay problemas de rendimiento ni nos preocupamos por la paz del mundo...

PEEEEEERO, el día de mañana tu cliente/jefe tiene la maravillosa idea de cambia todo tu código y programar en .NET, ¿qué pasa entonces? pues que en .NET tendrías que implementar también tu clase para hacer el mismo proceso.

La ventaja entonces de hacer estos procesos directamente en la BD's creo que es obvia. Si programas tus relaciones en el DBMS's los procesos para la integridad NO DEPENDEN DEL LENGUAJE DE PROGRAMACIÓN, que estés utilizando.

Vuelvo a recalcar lo mismo que dije desde un inicio NO HAY UNA MEJOR FORMA DE HACER LAS COSAS... pero si quieres mi opinión personal/profesional te digo lo siguiente.

1. UTILIZA siempre llaves foráneas.
2. USA siempre JOIN's
3. NO HAGAS COSAS DE BD's desde ningún lenguaje de programación.
4. HAZ CASO OMISO A LOS TRES PUNTOS ANTERIORES, si no aplican para tu caso.

Saludos
Leo
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Es necesario definir las relaciones entre tablas (PK->FK)?

Publicado por Leopoldo Taylhardat (43 intervenciones) el 14/05/2015 18:15:35
Saludos...

Te lo explico facilito...
ejemplo tablas: Paises-Estados(Departamentos...)-Poblaciones

La relación pais-estado está definidio que si no existe el pais NO PUEDE EXISTIR el estado...
Estado-Ciudad esta definido que si no existe el pais o el estado no puede existir la población...
Eso es lo que hace la integridad referencial...

Ahora vamos a lo otro...
Actualización en cascada...
Ejemplo...
Si cambias el nombre del pais automáticamente se actualizan los estados y las ciudades para el pais correspondiente..
Si cambias el nombre del estado automáticamente se actualizan los estados para las ciudades correspondientes...
Eliminación en cascada...
Si eliminas el pais automáticamente se eliminan los estados y las ciudades para el pais correspondiente..
Si eliminas el estado automáticamente se eliminan los estados para las ciudades correspondientes...

Si lo haces por trigger, tienes que crear un trigger para cada una de las condicionales de cada columna de cada tabla de la base de datos para que hagan eso...

Imagina una base de datos con 100 tablas (que podemos decir que es de tamaño mediano) y asumiendo dos (2) relaciones por tabla (de promedio) con tres (3) columnas de relación...
Estamos hablando de 100(tablas) X 2 procesos (update/delete) X 3 columnas = 600 procesos que tienes que programar en triggers para que tu base de datos se mantenga actualizada...
Y la programación de los insert es que el trigger anule el valor (set null) a insertar si no existe la tabla primaria...

NO es obligatorio definir las relaciones... eso queda a tu criterio...

Espero que te sirva...
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Es necesario definir las relaciones entre tablas (PK->FK)?

Publicado por Rolando (10 intervenciones) el 14/05/2015 20:17:31
Ferpecto, me queda clarísimo, es más, lo que dices es lo que siempre he echo, trabajo con metodología MVC y TODO lo que tiene que ver con las bases de datos, lo hago en Store Procedures o functions o triggers, y en mi código (siempre PHP), sólo invoco con CALL las cosas que necesito hacer...

La duda que tenía, era con respecto a la velocidad... y me lo dejaste muy claro.

Gracias y saludos!, me has sido de mucha ayuda!

Chaus!
-- ROLA
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar