# Jerarquías de datos Parte 1.1: Lista de Adyacencia con el núcleo de EF La lista de adyacencias es el enfoque más simple e intuitivo para almacenar datos jerárquicos - cada fila sólo apunta a su padre. Es lo que la mayoría de los desarrolladores alcanzan para el primero, y para árboles poco profundos con movimientos frecuentes, a menudo es la elección correcta. Este artículo cubre los detalles de implementación, incluyendo CTE recursivos para atravesar el árbol y construir estructuras anidadas para la pantalla de UI. ## Navegación en serie - [Parte 1: Sinopsis](/blog/efcore-hierarchical-data) - Introducción y comparación - **Parte 1.1: Lista de Adyacencias** (este artículo) - [Parte 1.2: Tabla de cierre](/blog/efcore-hierarchical-data-closure) - [Parte 1.3: Ruta materializada](/blog/efcore-hierarchical-data-path) - [Parte 1.4: Conjuntos anidados](/blog/efcore-hierarchical-data-nested) - [Parte 1.5: ltree](/blog/efcore-hierarchical-data-ltree) --- ## ¿Qué es una Lista de Adyacencias? El modelo de lista de adjacency es el enfoque que la mayoría de los desarrolladores alcanzan por primera vez, y con buena razón - es intuitivo. Cada nodo simplemente almacena una referencia a su padre. Si alguna vez has dibujado un árbol genealógico, ya has entendido este patrón. La característica clave: **cada fila sólo sabe acerca de su padre inmediato**. Para encontrar abuelos o nietos, usted necesita múltiples búsquedas o consultas recursivas. Este es el patrón más comúnmente documentado y está bien apoyado por [Relaciones de auto-referencia de EF Core](https://learn.microsoft.com/en-us/ef/core/modeling/relationships/self-referencing). [TOC] ## Definición de entidad La entidad es notablemente simple - sólo agregamos una auto-referencia anulable: ```csharp public class Comment { public int Id { get; set; } public string Content { get; set; } = string.Empty; public string Author { get; set; } = string.Empty; public DateTime CreatedAt { get; set; } // Foreign key - which blog post this comment belongs to public int PostId { get; set; } public BlogPost Post { get; set; } = null!; // ========== ADJACENCY LIST: The hierarchy is defined by these three properties ========== // ParentCommentId is nullable because: // - Root-level comments (direct replies to the post) have NULL // - Nested replies have the ID of the comment they're replying to public int? ParentCommentId { get; set; } // Navigation property to load the parent comment when needed // Useful for breadcrumb trails: "Post > Comment by Alice > Comment by Bob" public Comment? ParentComment { get; set; } // Navigation property to load immediate children (NOT grandchildren!) // EF Core populates this when you use .Include(c => c.Children) // NOTE: This only gives you ONE level deep - you won't see replies to replies public ICollection Children { get; set; } = new List(); } ``` ## Configuración del núcleo de EF La configuración establece la relación de auto-referenciación y agrega índices cruciales para las consultas que ejecutaremos más a menudo: ```csharp public class CommentConfiguration : IEntityTypeConfiguration { public void Configure(EntityTypeBuilder builder) { builder.HasKey(c => c.Id); builder.Property(c => c.Content) .IsRequired() .HasMaxLength(10000); builder.Property(c => c.Author) .IsRequired() .HasMaxLength(200); // Standard relationship: comment belongs to a blog post // Cascade delete here is safe - deleting a post should remove all its comments builder.HasOne(c => c.Post) .WithMany(p => p.Comments) .HasForeignKey(c => c.PostId) .OnDelete(DeleteBehavior.Cascade); // ========== THE SELF-REFERENCING RELATIONSHIP ========== // This is what makes it an adjacency list - each comment points to its parent builder.HasOne(c => c.ParentComment) .WithMany(c => c.Children) // One parent has many children .HasForeignKey(c => c.ParentCommentId) .OnDelete(DeleteBehavior.Restrict); // WARNING: Don't use Cascade here! // Why Restrict and not Cascade? // With Cascade, deleting a parent would automatically delete ALL children, // grandchildren, etc. This can be: // 1. Unexpected behaviour for users // 2. A database performance issue (many deletes) // 3. A data integrity risk (accidental mass deletion) // Better to handle subtree deletion explicitly in application code // ========== INDEXES: Critical for performance ========== // Index on ParentCommentId - used when loading children // "SELECT * FROM comments WHERE parent_comment_id = @id" builder.HasIndex(c => c.ParentCommentId); // Index on PostId - used when loading all comments for a post // "SELECT * FROM comments WHERE post_id = @id" builder.HasIndex(c => c.PostId); // Composite index for the most common query: // "Get all comments for a post, ordered by creation date" builder.HasIndex(c => new { c.PostId, c.CreatedAt }); } } ``` ## Esquema de base de datos El esquema resultante es mínimo - sólo una clave externa de auto-referencia: ```mermaid erDiagram COMMENT { int id PK string content string author datetime created_at int post_id FK int parent_comment_id FK "nullable - NULL for root comments" } BLOG_POST { int id PK string title string content } BLOG_POST ||--o{ COMMENT : "has" COMMENT ||--o{ COMMENT : "has children" ``` ## Operaciones ### Insertar un nuevo comentario Los insertos son muy simples - el patrón de la lista de adyacencias realmente brilla aquí: ```csharp public async Task AddCommentAsync( int postId, int? parentId, // NULL for root comment, parent's ID for a reply string author, string content, CancellationToken ct = default) { // Creating a comment is just setting the parent reference // No need to update closure tables, recalculate paths, or renumber anything var comment = new Comment { PostId = postId, ParentCommentId = parentId, // This single reference defines the hierarchy Author = author, Content = content, CreatedAt = DateTime.UtcNow }; context.Comments.Add(comment); await context.SaveChangesAsync(ct); logger.LogInformation("Added comment {CommentId} to post {PostId}", comment.Id, postId); return comment; } ``` ### Obtenga hijos inmediatos Consulta única indexada - rápida y sencilla: ```csharp public async Task> GetChildrenAsync(int commentId, CancellationToken ct = default) { // This is WHERE adjacency lists shine - getting children is trivial // Single indexed lookup: WHERE parent_comment_id = @id return await context.Comments .AsNoTracking() // Read-only, no tracking overhead .Where(c => c.ParentCommentId == commentId) // Uses the index we defined .OrderBy(c => c.CreatedAt) // Chronological order .ToListAsync(ct); } ``` ### Obtener antepasados (la parte difícil) Aquí es donde las listas de adyacencia muestran su debilidad.Sin consultas recursivas, tendrías que hacer múltiples viajes de ida y vuelta: obtener padres, padres de padres, abuelos... y así sucesivamente. Afortunadamente, PostgreSQL's [ETC recursivas](https://www.postgresql.org/docs/current/queries-with.html#QUERIES-WITH-RECURSIVE) ven al rescate: ```csharp public async Task> GetAncestorsAsync(int commentId, CancellationToken ct = default) { // WHY RAW SQL? // EF Core doesn't have great support for recursive CTEs // We need to drop down to raw SQL for this // HOW THE CTE WORKS: // 1. Start with the target comment (WHERE id = {0}) // 2. UNION ALL joins each result with its parent (JOIN on parent_comment_id) // 3. PostgreSQL keeps doing this until no more parents are found // 4. We exclude the starting comment (WHERE id != {0}) to get only ancestors var sql = @" WITH RECURSIVE ancestors AS ( -- Base case: start with our target comment SELECT * FROM comments WHERE id = {0} UNION ALL -- Recursive case: join each result with its parent SELECT c.* FROM comments c INNER JOIN ancestors a ON c.id = a.parent_comment_id ) -- Return all ancestors except the starting comment, in ID order (root first) SELECT * FROM ancestors WHERE id != {0} ORDER BY id"; return await context.Comments .FromSqlRaw(sql, commentId) .AsNoTracking() .ToListAsync(ct); } ``` ### Get Entire Subtree with Profundity También requiere un CTE recursivo, pero esta vez rastreamos la profundidad a medida que avanzamos: ```csharp public async Task> GetDescendantsWithDepthAsync( int commentId, CancellationToken ct = default) { // Similar to ancestors, but we go DOWN the tree instead of UP // We also track depth so we know how to indent in the UI var sql = @" WITH RECURSIVE descendants AS ( -- Base case: start with our target comment at depth 0 SELECT *, 0 as depth FROM comments WHERE id = {0} UNION ALL -- Recursive case: find children of each result, incrementing depth SELECT c.*, d.depth + 1 FROM comments c INNER JOIN descendants d ON c.parent_comment_id = d.id ) -- Return all descendants, ordered for display -- depth first, then by creation time within each level SELECT id, content, author, created_at, post_id, parent_comment_id, depth FROM descendants WHERE id != {0} ORDER BY depth, created_at"; // Note: We need a special DTO to capture the depth column // EF Core's FromSqlRaw won't automatically map extra columns to entity properties return await context.Database .SqlQueryRaw(sql, commentId) .ToListAsync(ct); } // DTO to hold comment data plus computed depth public class CommentWithDepth { public int Id { get; set; } public string Content { get; set; } = string.Empty; public string Author { get; set; } = string.Empty; public DateTime CreatedAt { get; set; } public int PostId { get; set; } public int? ParentCommentId { get; set; } public int Depth { get; set; } // Computed by the CTE } ``` ### Construyendo una estructura de árbol anidado para la interfaz de usuario A menudo lo que realmente necesita para renderizar es una estructura de árbol, no una lista plana. He aquí cómo construir uno de manera eficiente: ```csharp public async Task> GetCommentTreeAsync(int postId, CancellationToken ct = default) { // STRATEGY: // 1. Load ALL comments for the post in a single query (fast, one round trip) // 2. Build the tree structure in memory (also fast, just pointer manipulation) // Step 1: Get all comments for this post var allComments = await context.Comments .AsNoTracking() .Where(c => c.PostId == postId) .OrderBy(c => c.CreatedAt) // Consistent ordering .ToListAsync(ct); // Step 2: Create a lookup by parent ID // This gives us O(1) access to children of any comment var lookup = allComments.ToLookup(c => c.ParentCommentId); // Step 3: Build the tree starting from root comments (ParentCommentId = null) return BuildTree(lookup, null); } private List BuildTree( ILookup lookup, int? parentId) { // Recursively build tree nodes // lookup[parentId] gives us all comments whose parent is 'parentId' return lookup[parentId] .Select(c => new CommentTreeNode { Comment = c, Children = BuildTree(lookup, c.Id) // Recurse to get children }) .ToList(); } public class CommentTreeNode { public Comment Comment { get; set; } = null!; public List Children { get; set; } = new(); // Convenience property for UI public bool HasChildren => Children.Count > 0; } ``` ### Eliminar un subárbol Eliminar requiere encontrar a todos los descendientes primero: ```csharp public async Task DeleteSubtreeAsync(int commentId, CancellationToken ct = default) { // We need to find and delete all descendants, then the comment itself // Using a CTE to get all IDs, then bulk delete var sql = @" WITH RECURSIVE subtree AS ( SELECT id FROM comments WHERE id = {0} UNION ALL SELECT c.id FROM comments c INNER JOIN subtree s ON c.parent_comment_id = s.id ) DELETE FROM comments WHERE id IN (SELECT id FROM subtree)"; var deleted = await context.Database.ExecuteSqlRawAsync(sql, new object[] { commentId }, ct); logger.LogInformation("Deleted {Count} comments in subtree rooted at {CommentId}", deleted, commentId); } ``` ### Mover un subárbol Aquí es donde las listas de adyacencia realmente brillan - mover es trivial: ```csharp public async Task MoveSubtreeAsync( int commentId, int newParentId, CancellationToken ct = default) { // In adjacency list, moving a subtree is just updating ONE row! // All descendants automatically move with their parent because // their ParentCommentId still points to their direct parent var comment = await context.Comments.FindAsync(new object[] { commentId }, ct); if (comment == null) { throw new InvalidOperationException($"Comment {commentId} not found"); } // Prevent creating a cycle (moving a node under its own descendant) // This would create an infinite loop in our tree var ancestors = await GetAncestorsAsync(newParentId, ct); if (ancestors.Any(a => a.Id == commentId)) { throw new InvalidOperationException("Cannot move a comment under its own descendant"); } comment.ParentCommentId = newParentId; await context.SaveChangesAsync(ct); logger.LogInformation("Moved comment {CommentId} to new parent {NewParentId}", commentId, newParentId); } ``` ## Visualización del flujo de la consulta ```mermaid sequenceDiagram participant App as Application participant EF as EF Core participant DB as PostgreSQL Note over App,DB: Getting Children (Simple - O(1)) App->>EF: GetChildrenAsync(commentId) EF->>DB: SELECT * FROM comments WHERE parent_id = @id DB-->>EF: Results (indexed lookup) EF-->>App: List Note over App,DB: Getting Ancestors (Recursive - O(d) where d=depth) App->>EF: GetAncestorsAsync(commentId) EF->>DB: WITH RECURSIVE ancestors AS (...) DB->>DB: Traverse parent_id chain recursively DB-->>EF: All ancestors EF-->>App: List ``` ## Características del rendimiento Operación Complejidad Base de datos Round Trips Notas |-----------|------------|---------------------|-------| Insertar O(1) 1 Sólo establecer ParentCommentId Obtener hijos Obtener antepasados O(d) 1 (con CTE) d = profundidad, CTE trabaja en DB Obtener subárbol O(n) 1 (con CTE) n = tamaño del subárbol Mover subárbol O(1) 1 Sólo actualizar una fila Suprímase el subárbol del subárbol del subárbol del subárbol del subárbol del subárbol del subárbol del subárbol del subárbol del subárbol del subárbol del subárbol del subárbol del subárbol del subárbol del subárbol del subárbol del subárbol del subárbol del subárbol del subárbol del subárbol del subárbol del subárbol del subárbol. ## Pros y Contras Pros Cons |------|------| Simple de entender e implementar Conseguir ancestros/descendientes requiere consultas recursivas Almacenaje mínimo por encima (sólo una columna extra) Recursivo CTES puede ser lento en los árboles muy profundos Mover un subárbol es trivial (actualizar una fila) No hay manera fácil de obtener profundidad sin atravesar Las propiedades de navegación central de EF trabajan naturalmente No se puede contar fácilmente descendientes sin cargarlos No hay redundancia de datos para mantener Repetidas consultas para problemas N+1 si no es cuidadoso ## Cuándo usar la lista de adyacencia **Elija la Lista de Adyacencia cuando:** - Su jerarquía es superficial (menos de 5-6 niveles) - Usted mueve con frecuencia subárboles - Quieres que las propiedades de navegación de EF Core funcionen de forma natural. - Requisitos simples en los que los ETC recursivos son aceptables - Insertar rendimiento es más importante que leer rendimiento **Evite la Lista de Adyacencia cuando:** - Tiene jerarquías profundas (10+ niveles) - Usted consulta con frecuencia "todos los descendientes" o "todos los antepasados" - El rendimiento de lectura es crítico - Tienes que contar descendientes sin cargarlos. ## Navegación en serie - [Parte 1: Sinopsis](/blog/efcore-hierarchical-data) - **Parte 1.1: Lista de Adyacencias** (este artículo) - [Parte 1.2: Tabla de cierre](/blog/efcore-hierarchical-data-closure) - [Parte 1.3: Ruta materializada](/blog/efcore-hierarchical-data-path) - [Parte 1.4: Conjuntos anidados](/blog/efcore-hierarchical-data-nested) - [Parte 1.5: ltree](/blog/efcore-hierarchical-data-ltree)