mysql - una - Relación uno a muchos en la misma mesa
relacion uno a varios ejemplos (8)
Creo que lo mejor de todo es usar NestedSet http://www.doctrine-project.org/documentation/manual/1_0/en/hierarchical-data#nested-set
Simplemente configure actAs NestedSet
Estoy tratando de usar para definir una relación de uno a muchos en una sola tabla. Por ejemplo, digamos que tengo una tabla de Grupos con estas entradas:
Group: Group_1: name: Atlantic Records Group_2: name: Capital Records Group_3: name: Gnarls Barkley Group_4: name: Death Cab For Cutie Group_5: name: Coldplay Group_6: name: Management Company
El grupo Coldplay podría ser un hijo del grupo Capital Records y un hijo del grupo Management Company y Gnarls Barkley solo podría ser hijo de Atlantic Records.
¿Cuál es la mejor manera de representar esta relación? Estoy usando PHP y mySQL. También estoy usando PHP-Doctrine como mi ORM si eso ayuda.
Estaba pensando que necesitaría crear una tabla de enlace llamada group_groups que tuviera 2 columnas. owner_id y group_id. Sin embargo, no estoy seguro de si esa es la mejor manera de hacer esto.
Cualquier idea sería apreciada. Avíseme si le expliqué mi problema lo suficientemente bien.
(Supongo que hay una columna de identificación que puede usarse para referencias).
Puede agregar una columna llamada parent_id (allow nulls) y almacenar la identificación del grupo principal en ella. Luego puede unirse utilizando sql como: "Seleccione a. , B. Del grupo padre unirse grupo hijo en parent.id = child.parent_id".
Recomiendo usar una tabla separada para este enlace porque: 1. No puede admitir varios padres con un campo. Tienes que usar una tabla separada. 2. Importar / Exportar / Eliminar es mucho más difícil con un campo en la tabla porque puede encontrarse con conflictos clave. Por ejemplo, si intenta importar datos, debe asegurarse de importar primero los padres y luego los secundarios. Con una tabla separada, puede importar todos los grupos y luego todas las relaciones sin preocuparse por el orden real de los datos.
En esta instancia particular, sería aconsejable seguir los consejos de Ken G, ya que de hecho parece que estás modelando tres entidades separadas en una misma tabla.
En general, es posible que esto surja, si tuviera una mesa de "persona" y estuviera modelando quiénes eran todos los amigos, para un ejemplo artificial.
En este caso, de hecho tendrías una tabla "vinculante" o asociativa o matrimonial para administrar esas relaciones.
Estoy de acuerdo con Ken G y JohnMcG en que debe separar Administración y Etiquetas. Sin embargo, pueden estar olvidando que una banda puede tener múltiples gerentes y / o múltiples gerentes en un período de tiempo. En ese caso, necesitarías una relación de muchos a muchos.
- la administración tiene muchas bandas
- banda tiene mucha gestión
- etiqueta tiene muchas bandas
- banda tiene muchas etiquetas
En ese caso, su idea original de usar una tabla de relaciones es correcta. Es en casa donde se hacen muchas relaciones. Sin embargo, group_groups podría nombrarse mejor.
En última instancia, dependerá de sus requisitos. Por ejemplo, si está almacenando títulos de CD, quizás prefiera adjuntar etiquetas a un CD en particular en lugar de una banda.
Hay una serie de posibles problemas con este enfoque, pero con una comprensión mínima de los requisitos, aquí va:
Parece que en realidad hay tres ''entidades'' aquí: Artista / Banda, Label / Recording Co. y Management Co.
Los Artistas / Bandas pueden tener una Etiqueta / Grabación. Los Artistas / Bandas pueden tener una Compañía de Administración.
Label / Recording Co puede tener varios Artistas / Bandas
Management Co puede tener varios Artistas / Bandas
Entonces, hay relaciones uno a muchos entre Recording Co y Artists y entre Management Co y Artists.
Registre cada entidad solo una vez, en su propia tabla, con una ID única.
Coloque la clave del "uno" en cada instancia de "muchos"; en este caso, el Artista / Banda tendría una ID de Recording Co y una Id. De CoD Management.
Luego, su consulta finalmente se unirá a Artist, Recording Co y Management Co.
Con esta estructura, no necesita tablas de intersección, hay una clara separación de "entidades" y la consulta es relativamente simple.
Sí, necesitarías un puente que contuviera los campos que describes. Sin embargo, creo que su tabla debe dividirse si sigue el mismo tipo de entidades que usted describe.
Un par de opciones:
Más fácil: si cada grupo solo puede tener un padre, entonces solo necesita un campo "ParentID" en la tabla principal.
Si las relaciones pueden ser más complejas que eso, entonces sí, necesitarías algún tipo de tabla de enlaces. Tal vez incluso una columna de "tipo de relación" para definir qué tipo de relación entre los dos grupos.
Esto parece ser una combinación de STI (herencia de tabla única) y conjuntos anidados / estructuras de árbol. Los conjuntos / árboles anidados son uno de los padres de varios hijos:
http://jgeewax.wordpress.com/2006/07/18/hierarchical-data-side-note/