Teóricamente es necesario conocer este tipo de relación. Pero en la práctica, no es aconsejable por razones de performance o incluso del diseño en sí. Creo que serían casos muy puntuales y muy estrictamente necesarios dependiendo de las reglas de negocio. Tu explicación es muy completa y clara; gracias y Saludos.
Me alegra que este contenido te haya sido de ayuda. Aunque no lo se todo con gusto comparto el contenido. Si te ha servido te invito a suscribirte al canal para hacerlo crecer y seguir publicando mas contenido de este tipo
Es probable. Mi punto de vista es el siguiente. Esto representa una jerarquía Jefe-Subordinado. Si en tu caso la jerarquía tiene pocos niveles, dos o tres niveles, yo recomendaría modelarlas como relaciones jerárquicas en las cuales hay una tabla/entidad por cada nivel de la jerarquía. Pero si la jerarquía tiene muchos niveles o se tienen una jerarquía dinámica, donde la cantidad de niveles puede variar entonces creo la relación recursiva puede ser considerada. Como todo hay que evaluar que me conviene mas: quiero un mejor desempeño? Entonces tal vez la relación recursiva no sea lo adecuado. Quiero evitar llenar mi base de datos de muchas tablas por cada nivel, entonces la relación recursiva
Hola. Supongo que con MERE te refieres al Modelo Entidad Relacion y con MR al Modelo Relacional. Si es así, y la relación es 1:N es simple. Siempre les doy la analogía a mis alumnos de que el lado 1 es 'papá' y el lado es el 'hijo'. El hijo recibe el 'apellido' del papá. Con el apellido me refiero a la llave primaria o identificador principal.Sin embargo en este tipo especial de relación la misma tabla funge los 2 roles. Asi que hay que volver a colocar la llave primaria una vez mas pero ahora como foránea. No se puede llamar exactamente igual, así que se puede colocar algun nombre que indique que esa llave habla de un registro de la misma tabla pero con una jerarquía superior
Aunque creo no es algo muy común, ni muy recomendado por cuestión de desempeño, necesitarías agregar una tabla/entidad de intersección conectándola con 2 relaciones 1:N estando el lado N en la nueva entidad de intersección y teniendo esta nueva entidad 2 veces la llave primaria de la entidad base como llaves foráneas
@@artesanotecnologico5691 una relación jerarquica donde representes con una tabla/entidad cada nivel de esa jerarquia. Yo recomendaria eso cuando la jerarquia tiene pocos niveles. Por ejemplo en Mexico podriamos hablar de pais, estado y municipio, 3 niveles en la jerarquia. En el caso de multiples niveles o que los niveles sean dinámicos, es decir que puedan ser mas y luego menos pues la relación recursiva podria servirte
No. El campo de ese atributo puede ser null, en caso de que haya jefes que no tengan subordinados, todo depende de las necesidades que uno tenga. Porque si lo pones como not null ¿Cómo llamas a todos los jefes que no tengan subordinados? Saludos
Sí sería posible usar un 0 para un jefe jefe, pero si tenés que crear muchas instancias de esas sería preferible dejarlo vacío para llenar un campo menos... Es la única diferencia porque la consulta SQL sería column=0 o column IS NULL para llamar a todas esas instancias
Excelente explicación, buen contenido (Y).
Teóricamente es necesario conocer este tipo de relación. Pero en la práctica, no es aconsejable por razones de performance o incluso del diseño en sí. Creo que serían casos muy puntuales y muy estrictamente necesarios dependiendo de las reglas de negocio. Tu explicación es muy completa y clara; gracias y Saludos.
Así es buen vídeo, como mejorarías para mejorar el performance o el diseño.
MUY BUEN VÍDEO, Estaba buscando como crear una relación entre usuarios y referidos, esto me lo hace posible, excelente explicación gracias!!!!!
Me alegra que este contenido te haya sido de ayuda. Aunque no lo se todo con gusto comparto el contenido. Si te ha servido te invito a suscribirte al canal para hacerlo crecer y seguir publicando mas contenido de este tipo
Excelente. Gracias por la explicación.
Lo verdaderamente interesante sería ¿Cómo quedaría la consulta que devuelva ordenados jerárquicamente los resultados?
Gracias, me quedo claro.
Que bien que te haya servido
Mi pregunta es, no sería mejor crearle su propia tabla a jefe que herede de empledos?
Es probable. Mi punto de vista es el siguiente. Esto representa una jerarquía Jefe-Subordinado. Si en tu caso la jerarquía tiene pocos niveles, dos o tres niveles, yo recomendaría modelarlas como relaciones jerárquicas en las cuales hay una tabla/entidad por cada nivel de la jerarquía. Pero si la jerarquía tiene muchos niveles o se tienen una jerarquía dinámica, donde la cantidad de niveles puede variar entonces creo la relación recursiva puede ser considerada. Como todo hay que evaluar que me conviene mas: quiero un mejor desempeño? Entonces tal vez la relación recursiva no sea lo adecuado. Quiero evitar llenar mi base de datos de muchas tablas por cada nivel, entonces la relación recursiva
una consulta, como se traspasa este tipo de relación desde el MERE al MR??
Hola. Supongo que con MERE te refieres al Modelo Entidad Relacion y con MR al Modelo Relacional. Si es así, y la relación es 1:N es simple. Siempre les doy la analogía a mis alumnos de que el lado 1 es 'papá' y el lado es el 'hijo'. El hijo recibe el 'apellido' del papá. Con el apellido me refiero a la llave primaria o identificador principal.Sin embargo en este tipo especial de relación la misma tabla funge los 2 roles. Asi que hay que volver a colocar la llave primaria una vez mas pero ahora como foránea. No se puede llamar exactamente igual, así que se puede colocar algun nombre que indique que esa llave habla de un registro de la misma tabla pero con una jerarquía superior
@@OmarJasso entiendo en la primera tabla se pone el id principal y el foráneo de los hijos y se crea otra tabla con los hijos, muchas gracias estimado
@@amaro777_ si te estás refiriendo a una relación 1:N recursiva no se convierte en dos tablas, es solamente una
@@OmarJasso muchas gracias se paso, entiendo una tabla con dos llaves
@@OmarJasso excelente canal
Entonces se añade un atributo en vez de crear otra tabla no?
Muchas gracias, me ha quedado muy claro POR FIN xDDD
Que bien. Me alegra poder aportar
muy buena explicación, y como seria una recursiva muchos a muchos ?
Aunque creo no es algo muy común, ni muy recomendado por cuestión de desempeño, necesitarías agregar una tabla/entidad de intersección conectándola con 2 relaciones 1:N estando el lado N en la nueva entidad de intersección y teniendo esta nueva entidad 2 veces la llave primaria de la entidad base como llaves foráneas
@@OmarJasso entiendo con realcion a la repuesta de mi primera pregunta.
¿ como seria una relacion equivalente a una relacion recursiva ?
@@artesanotecnologico5691 una relación jerarquica donde representes con una tabla/entidad cada nivel de esa jerarquia. Yo recomendaria eso cuando la jerarquia tiene pocos niveles. Por ejemplo en Mexico podriamos hablar de pais, estado y municipio, 3 niveles en la jerarquia. En el caso de multiples niveles o que los niveles sean dinámicos, es decir que puedan ser mas y luego menos pues la relación recursiva podria servirte
El atributo de la relacion Empleado llamado numero jefe, debe de llevar implicito en el lenguaje DDL que es NOT NULL por problemas te integridad.
No. El campo de ese atributo puede ser null, en caso de que haya jefes que no tengan subordinados, todo depende de las necesidades que uno tenga. Porque si lo pones como not null ¿Cómo llamas a todos los jefes que no tengan subordinados? Saludos
No sería posible decir que el jefe jefe tiene numero_jefe = 0?
Sí sería posible usar un 0 para un jefe jefe, pero si tenés que crear muchas instancias de esas sería preferible dejarlo vacío para llenar un campo menos... Es la única diferencia porque la consulta SQL sería column=0 o column IS NULL para llamar a todas esas instancias
categoria
------------------
(pk) | id_cate
| nombre
| slug
| icono
(fk) | id_cate_padre
Es correcto Jhon Capcha
Pon mas ganas al hablar, parece que estas haciendo esto a la fuerza y sin ganas