[MySQL] Cuando las tablas están relacionadas
ZeRoberto
Fox Learner
Fox Learner
Ejemplo: crear una relación de uno a varios
La relación de uno a varios es la más común en una base de datos relacional. En una relación de este tipo, un registro de la tabla A puede tener más de un registro coincidente en la tabla B, pero cada registro de la Tabla B tendrá como máximo un registro coincidente en la tabla A.
Ejemplo: crear una relación de varios a varios
En una relación de varios a varios, un registro de la tabla A puede tener más de un registro coincidente en la tabla B y a un registro de la tabla B también puede corresponderle más de un registro de la tabla A. Este tipo de relación requiere cambios en el diseño de la base de datos para su correcta especificación en Visual FoxPro.
Para detectar relaciones de varios a varios entre las tablas es importante observar los dos sentidos de cada relación. Por ejemplo, considere la relación entre pedidos y productos de la base de datos de Importadores Tasmanian. Un pedido puede incluir más de un producto, de forma que para cada registro de la tabla Orders puede haber varios registros en la tabla Products. Pero eso no es todo: cada producto puede aparecer en varios pedidos, por lo que para cada registro de la tabla Products puede haber varios registros en la tabla Orders.
Los temas de las dos tablas (pedidos y productos) tienen una relación de varios a varios. Esto supone un problema en el diseño de la base de datos. Para entender este problema, imagine lo que ocurriría si intentase establecer la relación entre las dos tablas agregando el campo Product_id a la tabla Orders. Para tener más de un producto por pedido, necesitaría más de un registro en la tabla Orders por cada pedido real y tendría que repetir una y otra vez la información para cada registro relacionado con el mismo pedido, lo que supone un diseño poco eficaz que puede llevar a una falta de exactitud en los datos. El mismo problema aparece si se incluye el campo Order_id en la tabla Products: sería necesario más de un registro en la tabla Products para cada producto real. ¿Cómo puede resolverse este problema?
La respuesta consiste en crear una tercera tabla que divida la relación de varios a varios en dos relaciones de uno a varios. Esta tercera tabla se denomina tabla de unión, ya que actúa como conexión entre las dos tablas y en ella se incluirá la clave principal de cada una de las dos tablas anteriores.
Una tabla de conexión podría guardar únicamente las dos claves principales de las tablas que vincula o, como en la tabla Order_Line_Items, la tabla de conexión podría contener información adicional.
Ejemplo: crear una relación de uno a uno
En una relación de uno a uno, cada registro de la tabla A no puede tener más de un registro coincidente en la tabla B y a cada registro de la tabla B no puede corresponderle más de un registro coincidente en la tabla A. Este tipo de relación es poco habitual y puede indicar la necesidad de una modificación en el diseño de la base de datos.
Las relaciones de uno a uno entre dos tablas son poco usuales ya que, en muchos casos, la información de ambas tablas puede combinarse de forma sencilla en una tabla única.
Edgar Acevedo
Los datos "masivos" han existido desde siempre, aún en tiempos cuando no existía Oracle, SQL Server, etc.
Y desde aquellos tiempos "oscuros", cuando se usaba Foxpro para DOS versión 1.1 se usaban las relaciones en las tablas y no se sentía ninguna diferencia en el rendimiento de las mismas.
Estoy seguro que ya sabías esto, pero para orientar a algun otro colega del foro que vea este post, te hago la siguiente reminiscencia:
En 1,993 yo trabajaba en una oficina de gobierno que procesaba estadadísticas de encuestas. La tabla mas pequeña era de 70 mil registros y la mas grande de 950 mil registros. Usábamos DOS 6.2 en computadoras con procesador 286 y a veces, si teníamos suerte, usábamos una 386. Dos no podía en forma "nativa" usar mas de 640 Kb de RAM, por lo que había que cargar un "Manejador de memoria alta" que te permitía utilizar el Megabyte completo de RAM que traían esos equipos (si, solo 1 Mb de RAM). Los equipos los teníamos conectados en una red Novell Netware 2.12 de 10 usuarios con tarjetas Ethernet de 10 Mbps (que NO eran Full Duplex en ese tiempo). Finalmente usábamos Foxpro 2.5 o algo así...
Los reportes "nacían" por completo de tablas relacionadas guardadas mediante el parámetro ENVIRONMENT cuando creábamos el reporte. Había otra oficina que se jactaba de tener un IBM S/36, la edición "Baby" (que utilizaba como consola, una estación IBM XT). Ellos utilizaban un programa generador de consultas que corría en COBOL y se llamaba ÑQUERY.
Los reportes tardaban varios minutos en ejecutarse (algunos pasaban imprimiendo resultados toda la noche), pero aún así, le "dábamos por toda la torre" (vencíamos facilmente) al IBM S/36 y su ÑQUERY.
Desde esa fecha me acostumbré a usar los SET RELATION en sus diferentes formas y nunca sentí una sola merma en la velocidad de rendimiento del poderoso zorro. Eso si, las relaciones siempre las armo y desarmo "sobre la marcha", nunca las he definido de entrada en la DBC. Muchos programadores prefieren sustituirlas con sentencias SQL, bien por ellos. Yo sigo usándolas con mucho éxito y facilidad y aunque he intentado reemplazarlas por sentencias SQL, no he logrado que estas corran tan rápido como las relaciones (algo estaré haciendo mal...).
En fin, no he querido salir de mi "zona cómoda" y sigo usándolas en varias tablas enormes (de 1 millón y medio de registros). Incluso utilizo mucho el SET SKIP TO y siempre me resulta muy bien.
Saludos,
Edgar Acevedo
--
Walter R. Ojeda Valiente
Saludos.
Walter.
"Si puedes razonar con gente religiosa, no son gente religiosa". Dr. House
Date: Tue, 13 Nov 2012 12:19:01 -0500
Subject: [vfp] [MySQL] Cuando las tablas están relacionadas
From: zero...@gmail.com
To: publice...@googlegroups.com
mpulla
Hola Roberto.
No solo las relaciones afectan al tiempo de repuesta, están los índices, Trigers, restricciones reglas y demás cosas que hayas implementado en tu db, pero como dice Walter en la mayoria de los casos son milésimas de segundo.
Saludos.
Mauricio
ZeRoberto
--
Edgar Acevedo
Salu2,
Edgar
--
mpulla
Hola Roberto.
El Update al igual que el Select, Deleted, Insert se valen de los Indices, si tienes los índices correctos y bien definidos vas a sentirlo mucho menos, cualquiera de los sentencias es un proceso, dependiendo de los índices y su definición, con sql Server puedes ver lo que pasa con el plan de ejecución supongo que MySql tienes algo parecido.
Saludos.
Mauricio