Nueva pregunta

Pregunta:

 
  1  
 
Fecha: 09-04-2018 02:39:20 (En Español)

BBDD, ¿De qué manera es una buena práctica?[No resuelta]

Hola compañer@s,

estoy haciendo una nueva base de datos para un proyecto, y estaba haciéndola tal cual me enseñaron, que es, para relacionar 2 tablas hacer una tercera, y sobre la tercera hacer la foreing_key, la manera de la que me enseñaros sería en el ejemplo así:

TABLA ALERTAS
id, texto, fecha_creacion

TABLA USUARIOS
id, nombre, apellidos, etc, tec

TABLA ALERTAS_USUARIOS
id_usuario, id_alerta, fecha_lectura

fk_usuario_alertas_usuarios on_update, on_delete -> id_usuario

Y mi pregunta es la siguiente, ¿que más daría si en vez de hacer una tercera tabla, eliminamos la tabla ALERTAS_USUARIOS y la tabla de alertas le ponemos 2 datos más quedando así?

TABLA ALERTAS
id, texto, fecha_creacion, fecha_lectura, id_usuario

fk_usuario_alertas on_update, on_delete -> id_usuario


Desde ya!, gracias por vuestro tiempo.
Etiquetas: Base de Datos - Mejores Prácticas - MySQL - MySQL Desarrollo - Pregunta Votos: 1 - Respuestas: 12 - Vistas: 18 Compartir en: Google Facebook Twitter LinkedIn Link
 

Respuestas:

  • Fecha: 09-04-2018 08:01:32 Hola Fran,
    No sé quién te enseñó eso pero no es una fórmula general.
    Ese caso que te enseñaron solamente aplica si tienes una relación muchos a muchos.
    En el caso de que sea una relación uno a muchos entonces la situación cambia pues tu llave foránea se puede almacenar en la tabla dependiente, como bien lo haces en el segundo caso.

    Todo eso se ve claramente si normalizas adecuadamente tus base de datos.
      Votos: 1 - Link respuesta
     
  •  
      0  
     
    Fecha: 09-04-2018 08:41:08 Muchas gracias Ernesto por tu respuesta.

    Entonces en el caso del ejemplo, muchos usuarios pueden tener muchas alertas... sería el primer caso en vez del segundo? o lo he entendido mal.

    Gracias de nuevo
      Votos: 0 - Link respuesta
     
  • Fecha: 09-04-2018 08:54:04 La utilizacion de una tercera tabla es para agilizar las cosas, ya que al cargar solo una tabla de llaves (key) esta indexado y es mas rapido... Se nota cuando tu llamada involucra muchos mas campos y claro un resultado extenso de una gran información.
    Si no trabajaras con millones de resultados entonces no hay problema cual ocupes... pero para una entiedad relacion mas estructurada, es mejor la tercera..
    Al final, hacen casi lo mismo, si es muy poca la informacion y si es mucha su diferencia es de + - 10 segundos...
    en si muchos ponen en la entidad relacion una tercera, pero muchos la interpretan solo como una relacion mas...

    Nota: en lo personal no ocupo la tercera, al menos que guarde mas informacion, sino, es solo redundancia de datos...

    Saludos...
    Stryfe™
      Votos: 1 - Link respuesta
     
  • Fecha: 09-04-2018 08:56:31 Aqui un par de ejemplos:

    Relación de Muchos a Muchos:



    relación de pocos a Muchos:
      Votos: 2 - Link respuesta
     
  • Fecha: 09-04-2018 18:57:16 Estrictamente hablando sólo hay 4 tipos de relaciones:

    - Auto referenciadas. Un registro de una tabla hace referencia a otro registro de la misma tabla. Aquí tu llave foránea apunta a la llave primaria de la misma tabla. Por ejemplo una tabla que guarda departamentos de una empresa que a su vez se dividen en otros departamentos.

    - 1 a 1. Un registro de la tabla A referencía a un registro de la tabla B y este a su vez referencía a uno de la tabla A. Son casos muy raros y hay muchas discusiones sobre el tema (optimización de consultas con registros muy grandes, segmentación de datos, optimizar el uso de memoria, etc.) La llave primaria de la tabla B es generalmente la misma llave foránea que apunta a la tabla A. Solo debe existir un registro relacionado en ambas direcciones. Por ejemplo una tabla de empleados y otra tabla que sea detalles_empleado

    - 1 a muchos (1-m). Varios registros de la tabla B hacen referencia a un registro de la tabla A. Aquí la llave foránea de la tabla B apunta a la llave primaria de la tabla A. Por ejemplo una tabla de departamentos y otra de empleados donde muchos empleados pertenecen a un solo departamento.

    - muchos a muchos (n-m). Varios registros de la tabla A hacen referencia a un registro de la tabla B y varios registros de la tabla B hacen referencia a un registro de la tabla A. Aquí es donde utilizas una tabla de relación como la que mencionas. Por ejemplo una tabla país, otra tabla persona y una tercera que se llame ciudadano. Una persona puede ser ciudadano de varios países y un país tiene múltiples ciudadanos. La tabla que almacena la relación sería la tabla ciudadano.

    Espero que esto aclare más el tema.

    Saludos
      Votos: 5 - Link respuesta
     
  • Fecha: 10-04-2018 11:06:58 No he estudiado mucha teoría de datos, pero las relaciones son de uno a varios o de varios a varios, da igual que sean muchos o pocos.

    Una tercera tabla de enlace solo se necesita cuando las relaciones son de varios a varios.
      Votos: -1 - Link respuesta
     
  •  
      0  
     
    Fecha: 10-04-2018 22:28:48 Aprovecho esta pregunta para realizar una relacionada...

    Cuando hago una foreing key, siempre es obligatorio que al insertar datos estos sean relacionados?

    Me explico, cuando relleno los datos de un inmueble pero en ese momento no tengo la provincia, se guarda como valor 0, pero como 0 no coincide con ningún valor de provincia me da el siguiente error:

    #1452 - Cannot add or update a child row: a foreign key constraint fails (`crmbd`.`inmuebles`, CONSTRAINT `fk_provincias_inmuebles` FOREIGN KEY (`id_provincia`) REFERENCES `provincias` (`id`) ON UPDATE CASCADE)
      Votos: 0 - Link respuesta
     
  • Fecha: 11-04-2018 03:05:58 Así es Fran una vez que relacionaste, se deben llenar las tablas en orden.

    Es decir ahora primero las tablas relacionadas y después la tabla que tiene la relación.
      Votos: 1 - Link respuesta
     
  •  
      0  
     
    Fecha: 11-04-2018 03:42:25 Ok, entonces si necesito que se puedan dejar valores a 0, en un momento dado, o sea que no tenga relación, debería eliminar la foreing key?,

    Pero si así fuera, podría haber inconsistencia de datos no?

    El tema es que de un inmueble hay muchísimos datos pero para crearlo solo necesito la fecha de creación y el id del usuario que lo crea, y es en esos casos cuando me dice mysql que hay un error.

    Como gestionáis vosotros casos como este?
      Votos: 0 - Link respuesta
     
  • Fecha: 11-04-2018 04:39:03 Entonces no estas haciendo una definición correcta. En cuanto a la teoría lo que necesitas leer se llama: "Normalización de base de datos", busca libros digitales sobre este tema que te ayudará a corregir la estructura de tu base de datos y agregar los elementos que se necesitan adicionales.   Votos: 0 - Link respuesta
     
  • Fecha: 12-04-2018 18:29:28 Hola

    Carlos y Ernesto te han brindado unos muy claros ejemplos. +1 para ellos.

    Te dejo un excelente videotutorial creado por Fernando Mosquera que te ayudara a entender un poco mejor el tema

    Temas del video:


    - Instalación de un Entorno de Trabajo para MySQL (Herramienta MySQL Workbench 6 en Sistema Operativo Ubuntu 14.04 (32bit)
    - Modelado DER (Diagrama de Entidad Relación) y Creación de Bases de Datos MySQL

    Diagrama de Entidad Relación

    Instalación de MySQL Workbench, modelado (DER) y creación de bases de datos MySQL (en español)




    MySQL Workbench descarga Aquí


    Espero que te sirva
    Saludos
      Votos: 2 - Link respuesta
     
  •  
      0  
     
    Fecha: 15-04-2018 20:45:09 Gracias Walter, muy interesante el vídeo de Fernando y muy bien explicado   Votos: 0 - Link respuesta
     
Para participar activamente de la comunidad primero debes autenticarte, ingresa al sistema.Iniciar Sesión