2009-06-01 26 views
125

¿Cuál sería la mejor manera de implementar una estructura de datos de árbol personalizable (es decir, una estructura de árbol con un número desconocido de árboles) en una base de datos?Estructura de la base de datos para estructura de datos de árbol

He hecho esto una vez antes de usar una tabla con una clave externa a sí mismo.

¿Qué otras implementaciones podría ver y esta implementación tiene sentido?

+3

Ver: [¿Cuáles son las opciones para almacenar datos jerárquicos en una base de datos relacional?] (Http://stackoverflow.com/questions/4048151/what-are-the-options-for-storing-hierarchical-data-in -a-relational-database) – cbare

+0

SQL Server (desde 2008) ofrece el [tipo de datos hierarchyid] (https://msdn.microsoft.com/en-us/library/bb677290.aspx) – BornToCode

Respuesta

63

Usted menciona la aplican con mayor frecuencia, que es lista de adyacencia: https://blogs.msdn.microsoft.com/mvpawardprogram/2012/06/25/hierarchies-convert-adjacency-list-to-nested-sets

Hay otros modelos, así, como camino materializado y conjuntos anidados: http://communities.bmc.com/communities/docs/DOC-9902

Joe Celko ha escrito un libro sobre este sujeto, que es una buena referencia desde una perspectiva general de SQL (se menciona en el enlace del artículo conjunto anidado más arriba).

Además, Itzik Ben-Gann tiene una buena descripción de las opciones más comunes en su libro "Dentro de Microsoft SQL Server 2005: consultas T-SQL".

Los principales aspectos a considerar al elegir un modelo son:

1) Frecuencia de cambio de estructura - ¿Con qué frecuencia la estructura real del cambio árbol. Algunos modelos proporcionan mejores características de actualización de estructura. Sin embargo, es importante separar los cambios de estructura de otros cambios de datos. Por ejemplo, es posible que desee modelar el organigrama de una empresa. Algunas personas modelarán esto como una lista de adyacencia, utilizando la identificación del empleado para vincular a un empleado con su supervisor. Este suele ser un enfoque subóptimo. Un enfoque que a menudo funciona mejor es modelar la estructura organizativa por separado de los propios empleados, y mantener al empleado como un atributo de la estructura. De esta forma, cuando un empleado abandona la empresa, la estructura organizativa en sí misma no necesita cambios, solo la asociación con el empleado que se fue.

2) ¿El árbol es pesado o pesado para leer? Algunas estructuras funcionan muy bien al leer la estructura, pero incurren en gastos adicionales al escribir en la estructura.

3) ¿Qué tipos de información necesita obtener de la estructura? Algunas estructuras se destacan por proporcionar ciertos tipos de información sobre la estructura. Los ejemplos incluyen encontrar un nodo y todos sus elementos secundarios, encontrar un nodo y todos sus padres, encontrar el recuento de nodos secundarios que cumplan ciertas condiciones, etc.Necesita saber qué información se necesitará de la estructura para determinar la estructura que mejor se adapte a sus necesidades.

+0

Hola, me estoy enfrentando exactamente este mismo problema en la pregunta y me gustaría hacerle una pregunta sobre los temas anteriores. Considerando una estructura como en el tema número uno (tabla estructurada organizacional (no estructurada por el empleado) con ParentId referenciada en la misma tabla), necesito establecer quién es el jefe de un área determinada. Asignaré a todos los empleados de ese área específica directamente. ¿Dónde colocarías al jefe de esa área específica? Dentro de la misma área o un gorup arriba? Mi enfoque es hacer referencia a él/ella al grupo de arriba, eso me da una mejor estructura, creo. Gracias. –

+1

El primer enlace parece estar roto. –

+0

@J. C. Leitão - Gracias, he actualizado el enlace. – JeremyDWill

48

Eche un vistazo a Managing Hierarchical Data in MySQL. Discute dos enfoques para almacenar y administrar datos jerárquicos (tipo árbol) en una base de datos relacional.

El primer enfoque es el modelo de lista de adyacencia, que es lo que esencialmente describe: tener una clave externa que se refiere a la tabla en sí. Si bien este enfoque es simple, puede ser muy ineficiente para ciertas consultas, como la construcción de todo el árbol.

El segundo enfoque discutido en el artículo es el modelo de conjunto anidado. Este enfoque es mucho más eficiente y flexible. Consulte el artículo para obtener una explicación detallada y consultas de ejemplo.

+0

su enlace tiene un tema muy interesante siendo discutido. ¡Gracias! – Fritz

2

Tener una tabla con una clave externa para sí mismo tiene sentido para mí.

A continuación, puede utilizar una expresión de tabla común en SQL o la conexión por declaración anterior en Oracle para construir su árbol.

+0

Tengo una tabla de registro, con una columna de identidad LogID, y una columna ParentLogID con un FK que apunta a la columna LogID. Cuando se escribe la primera fila de registro en una transacción, obtengo SCOPE_IDENTITY(). Todos los demás registros se escriben con este valor en la columna ParentLogID. Esto es realmente útil para agrupar filas que pertenecen juntas. Es la única manera real de ver lo que sucedió, sin esto, sería un gran lío de filas de registro de múltiples transacciones, todas mezcladas. –

+0

@KM - Dijo que "tiene sentido" y que "no tiene sentido" –

1

he utilizado la siguiente implementación en SQL SERVER 2005. Comprobar here

8

Si usted tiene que utilizar bases de datos relacionales para organizar la estructura de datos de árbol continuación PostgreSQL tiene módulo ltree fresco que ofrece el tipo de datos para representar las etiquetas de los datos almacenados en una estructura jerárquica en forma de árbol. Puede obtener la idea desde allí. (Para obtener más información, consulte: http://www.postgresql.org/docs/9.0/static/ltree.html)

En común, LDAP se utiliza para organizar registros en una estructura jerárquica.

Cuestiones relacionadas