Back to "Datahierarkier Part 1.3: Materialiserad väg med EF Core"

This is a viewer only at the moment see the article on how this works.

To update the preview hit Ctrl-Alt-R (or ⌘-Alt-R on Mac) or Enter to refresh. The Save icon lets you save the markdown file to disk

# Datahierarkier Part 1.3: Materialiserad väg med EF Core

<datetime class="hidden">2025-12-06T09:30</datetime>

Materialiserade vägar lagrar den kompletta ursprunget som en avgränsad sträng - som `/1/3/7/` - gör förfäder omedelbart läsbara utan några anknytningar . Perfekt för brödkrummens skapande och människan

## Seri Navigation

- [Del 1: Übersicht](/blog/efcore-hierarchical-data) - Inleiding och jämförelse
- [Del 1.1: Närliggande lista](/blog/efcore-hierarchical-data-adjacency)
- [Del 1.2: Slutbrädan](/blog/efcore-hierarchical-data-closure)
- **Del 1.3: Materialiserad väg** (den här artikeln )
- [Del 1.4: Nested Sets](/blog/efcore-hierarchical-data-nested)
- [Del 1.5: ltree](/blog/efcore-hierarchical-data-ltree)

---

## Vad är en materialiserad väg?

Materialiserad vägsmönster ( kallas också "Tålberäkningen" i [Joe Celko, MSK: s träd och hierarkier](https://www.amazon.com/Hierarchies-Smarties-Kaufmann-Management-Systems/dp/0123877334)) sparar den kompletta ursprunget till varje nod som en avgränsad sträng | - | som ett filepath eller postaladress |. | Istället för att spara bara | " | min moder är nod | МSK4 | sparar vi | |

Tänk på det som att lagra hela URL istället för bara sidans namn. vägen `/blog/posts/2024/my-article` talar om exakt var du är i hierarkin

**Nyckelinsikten:** Vi' är affärskrångliga sökningar för storvarad överskott . Förfäderna är denormaliserade in i varje rad, men detta gör förfädernas sökningar triviala.

[TOC]

## Konceptet visualiserat

```mermaid
flowchart TD
 subgraph "Comment Tree"
 C1["Comment 1 Path: /1/"]
 C2["Comment 2 Path: /1/2/"]
 C3["Comment 3 Path: /1/3/"]
 C4["Comment 4 Path: /1/3/4/"]
 end

C1 --> C2
    C1 --> C3
    C3 --> C4

subgraph "What the paths tell us"
 P1["Comment 4's path /1/3/4/ means: • Ancestors are 1, 3 (parse the path) • Depth is 3 (count separators - 1) • Root is 1 (first element)"]
 end

style C1 stroke:#6366f1,stroke-width:2px
    style C2 stroke:#8b5cf6,stroke-width:2px
    style C3 stroke:#8b5cf6,stroke-width:2px
    style C4 stroke:#a855f7,stroke-width:2px
```

Pathen är själv

- **Att läsa förfäder:** Förefatta `/1/3/4/` → förfäder är [1, 3, 4]
- **Att hitta barnbarn:** Fråga `WHERE path LIKE '/1/3/%'` → får allt under noden 3
- **Beräkning av djupet:** räkna separatorna minus ett
- **Att hitta syskon:** Fråga `WHERE path LIKE '/1/3/_/'` (medelbara barn av 3)

## Enhetens definition

Enheten lägger till en enda vägs kolumn:

```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; }

public int PostId { get; set; }
    public BlogPost Post { get; set; } = null!;

// ========== MATERIALISED PATH ==========

// The complete path from root to this node
    // Format: /ancestor1/ancestor2/.../thisNode/
    // Examples:
    //   Root comment: "/1/"
    //   Child of 1: "/1/5/"
    //   Grandchild: "/1/5/12/"
    //
    // The leading and trailing slashes make pattern matching easier:
    // - LIKE '/1/%' finds all descendants of 1 (includes /1/ itself)
    // - LIKE '/1/5/%' finds all descendants of 5 under 1
    public string Path { get; set; } = string.Empty;

// We still keep ParentCommentId for:
 // 1. Quick "who is my parent" without parsing
 // 2. EF Core navigation properties
 // 3. Data integrity (can validate path matches parent relationship)
 public int? ParentCommentId { get; set; }
 public Comment? ParentComment { get; set; }
 public ICollection<Comment> Children { get; set; } = new List<Comment>();

// ========== COMPUTED HELPERS ==========

// Parse ancestors from path - not stored, computed on demand
 public IEnumerable<int> GetAncestorIds()
 {
 if (string.IsNullOrEmpty(Path)) yield break;

// Split "/1/3/4/" into ["", "1", "3", "4", ""]
        var parts = Path.Split('/', StringSplitOptions.RemoveEmptyEntries);

// Return all except the last (which is this node's ID)
 for (int i = 0; i < parts.Length - 1; i++)
 {
 if (int.TryParse(parts[i], out var id))
 yield return id;
 }
 }

// Calculate depth from path
    public int GetDepth()
    {
        if (string.IsNullOrEmpty(Path)) return 0;
        // Count segments: "/1/3/4/" has 3 segments, depth is 2 (0-indexed from root)
        return Path.Split('/', StringSplitOptions.RemoveEmptyEntries).Length - 1;
    }
}
```

## EF Core Konfiguration

```csharp
public class CommentConfiguration : IEntityTypeConfiguration<Comment>
{
 public void Configure(EntityTypeBuilder<Comment> builder)
 {
 builder.HasKey(c => c.Id);

builder.Property(c => c.Content)
            .IsRequired()
            .HasMaxLength(10000);

builder.Property(c => c.Author)
            .IsRequired()
            .HasMaxLength(200);

// ========== PATH COLUMN ==========
        // Set a reasonable max length - this limits your tree depth
        // /1/12345/12346/12347/...
        // Each segment is up to ~7 chars (ID + slash), so 1000 chars ≈ 140 levels
        builder.Property(c => c.Path)
            .IsRequired()
            .HasMaxLength(1000);

// Relationship to blog post
        builder.HasOne(c => c.Post)
            .WithMany(p => p.Comments)
            .HasForeignKey(c => c.PostId)
            .OnDelete(DeleteBehavior.Cascade);

// Self-referencing (optional but useful)
        builder.HasOne(c => c.ParentComment)
            .WithMany(c => c.Children)
            .HasForeignKey(c => c.ParentCommentId)
            .OnDelete(DeleteBehavior.Restrict);

// ========== INDEXES ==========

// Standard indexes
        builder.HasIndex(c => c.PostId);
        builder.HasIndex(c => c.ParentCommentId);

// PATH INDEX - Critical for performance!
        // This makes LIKE 'prefix%' queries efficient
        // PostgreSQL can use a B-tree index for prefix LIKE patterns
        // (but NOT for '%suffix' or '%contains%' patterns)
        builder.HasIndex(c => c.Path);

// For PostgreSQL, a text_pattern_ops index is even better for LIKE:
        // CREATE INDEX ix_comments_path ON comments (path text_pattern_ops);
        // You may want to add this via a raw migration
    }
}
```

## Databaseringsschema

```mermaid
erDiagram
    COMMENT {
        int id PK
        string content
        string author
        datetime created_at
        int post_id FK
        int parent_comment_id FK "optional"
        string path "e.g. /1/3/7/"
    }

BLOG_POST {
        int id PK
        string title
        string content
    }

BLOG_POST ||--o{ COMMENT : "has"
    COMMENT ||--o{ COMMENT : "parent-child"
```

## Operationer

### Insert a New Comment

Inseration kräver att bygga vägen från moderen

```csharp
public async Task<Comment> AddCommentAsync(
 int postId,
 int? parentId,
 string author,
 string content,
 CancellationToken ct = default)
{
 string path;

if (parentId.HasValue)
    {
        // Get parent's path to extend it
        var parentPath = await context.Comments
            .Where(c => c.Id == parentId.Value)
            .Select(c => c.Path)
            .FirstOrDefaultAsync(ct);

if (parentPath == null)
        {
            throw new InvalidOperationException($"Parent comment {parentId} not found");
        }

// We need the ID first, so we'll update the path after saving
        // (Chicken-and-egg: path contains our ID, but we don't have ID until saved)

var comment = new Comment
        {
            PostId = postId,
            ParentCommentId = parentId,
            Author = author,
            Content = content,
            CreatedAt = DateTime.UtcNow,
            Path = string.Empty  // Temporary - will update after save
        };

context.Comments.Add(comment);
        await context.SaveChangesAsync(ct);

// Now we have the ID - build the real path
        // Parent path "/1/3/" + our ID "7" = "/1/3/7/"
        comment.Path = $"{parentPath}{comment.Id}/";
        await context.SaveChangesAsync(ct);

logger.LogInformation("Added comment {CommentId} with path {Path}", comment.Id, comment.Path);
        return comment;
    }
    else
    {
        // Root comment - path is just our ID
        var comment = new Comment
        {
            PostId = postId,
            ParentCommentId = null,
            Author = author,
            Content = content,
            CreatedAt = DateTime.UtcNow,
            Path = string.Empty  // Temporary
        };

context.Comments.Add(comment);
        await context.SaveChangesAsync(ct);

comment.Path = $"/{comment.Id}/";
        await context.SaveChangesAsync(ct);

logger.LogInformation("Added root comment {CommentId} with path {Path}", comment.Id, comment.Path);
        return comment;
    }
}
```

### få omedelbart barn

Att använda moderen- relation till barn ( vi behöll moderKommentid för bekvämlighet ):

```csharp
public async Task<List<Comment>> GetChildrenAsync(int commentId, CancellationToken ct = default)
{
 // Option 1: Use ParentCommentId (simple, always works)
 return await context.Comments
 .AsNoTracking()
 .Where(c => c.ParentCommentId == commentId)
 .OrderBy(c => c.CreatedAt)
 .ToListAsync(ct);

// Option 2: Use path pattern (demonstrates path power)
 // var parentPath = await context.Comments
 // .Where(c => c.Id == commentId)
 // .Select(c => c.Path)
 // .FirstOrDefaultAsync(ct);
 //
 // if (parentPath == null) return new List<Comment>();
 //
 // // Find paths that extend parent by exactly one segment
 // // Parent: /1/3/ Children: /1/3/X/ where X is one number
 // var childPathPattern = $"{parentPath}%";
 //
 // return await context.Comments
 // .AsNoTracking()
 // .Where(c => EF.Functions.Like(c.Path, childPathPattern)
 // && c.Path != parentPath
 // && c.ParentCommentId == commentId) // Ensures immediate children only
 // .ToListAsync(ct);
}
```

### få alla förfäder

Det är här som materialiserade vägar skiner - analysera vägen , inga datauppsök behöver göras

```csharp
public async Task<List<Comment>> GetAncestorsAsync(int commentId, CancellationToken ct = default)
{
 // Step 1: Get the path (single query)
 var path = await context.Comments
 .Where(c => c.Id == commentId)
 .Select(c => c.Path)
 .FirstOrDefaultAsync(ct);

if (string.IsNullOrEmpty(path))
 return new List<Comment>();

// Step 2: Parse ancestor IDs from path
    // Path "/1/3/7/" -> split -> ["1", "3", "7"] -> take all but last -> [1, 3]
    var ancestorIds = path
        .Split('/', StringSplitOptions.RemoveEmptyEntries)
        .SkipLast(1)  // Exclude self
        .Select(int.Parse)
        .ToList();

if (!ancestorIds.Any())
 return new List<Comment>();

// Step 3: Fetch ancestors (single query, uses primary key index)
    var ancestors = await context.Comments
        .AsNoTracking()
        .Where(c => ancestorIds.Contains(c.Id))
        .ToListAsync(ct);

// Step 4: Order by position in path (root first)
    return ancestorIds
        .Select(id => ancestors.First(a => a.Id == id))
        .ToList();
}
```

### få alla barnbarn

Använd LIKE med prefixet path:

```csharp
public async Task<List<Comment>> GetDescendantsAsync(int commentId, CancellationToken ct = default)
{
 // Get the path first
 var path = await context.Comments
 .Where(c => c.Id == commentId)
 .Select(c => c.Path)
 .FirstOrDefaultAsync(ct);

if (string.IsNullOrEmpty(path))
 return new List<Comment>();

// LIKE 'path%' finds all paths that START with this path
    // Path "/1/3/" matches "/1/3/", "/1/3/5/", "/1/3/5/9/", etc.
    // Using EF.Functions.Like for proper SQL generation
    return await context.Comments
        .AsNoTracking()
        .Where(c => EF.Functions.Like(c.Path, $"{path}%") && c.Id != commentId)
        .OrderBy(c => c.Path)  // Gives us depth-first order!
        .ToListAsync(ct);
}
```

### få barnbarn med djup

Vi kan räkna ut djupet från vägen:

```csharp
public async Task<List<CommentWithDepth>> GetDescendantsWithDepthAsync(
 int commentId,
 int? maxDepth = null,
 CancellationToken ct = default)
{
 var comment = await context.Comments
 .AsNoTracking()
 .FirstOrDefaultAsync(c => c.Id == commentId, ct);

if (comment == null)
 return new List<CommentWithDepth>();

var basePath = comment.Path;
    var baseDepth = basePath.Split('/', StringSplitOptions.RemoveEmptyEntries).Length;

// Get all descendants
    var query = context.Comments
        .AsNoTracking()
        .Where(c => EF.Functions.Like(c.Path, $"{basePath}%") && c.Id != commentId);

var descendants = await query.ToListAsync(ct);

// Calculate relative depth and filter if needed
 var result = descendants
 .Select(d =>
 {
 var absoluteDepth = d.Path.Split('/', StringSplitOptions.RemoveEmptyEntries).Length;
 var relativeDepth = absoluteDepth - baseDepth;
 return new CommentWithDepth
 {
 Id = d.Id,
 Content = d.Content,
 Author = d.Author,
 CreatedAt = d.CreatedAt,
 PostId = d.PostId,
 ParentCommentId = d.ParentCommentId,
 Path = d.Path,
 Depth = relativeDepth
 };
 })
 .Where(d => !maxDepth.HasValue || d.Depth <= maxDepth.Value)
 .OrderBy(d => d.Path)
 .ToList();

return result;
}

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 string Path { get; set; } = string.Empty;
    public int Depth { get; set; }
}
```

### Lösa ett underträd

Enkel med vägsmatchning:

```csharp
public async Task DeleteSubtreeAsync(int commentId, CancellationToken ct = default)
{
    var path = await context.Comments
        .Where(c => c.Id == commentId)
        .Select(c => c.Path)
        .FirstOrDefaultAsync(ct);

if (string.IsNullOrEmpty(path))
    {
        throw new InvalidOperationException($"Comment {commentId} not found");
    }

// Delete all comments whose path starts with this path
    // This includes the comment itself and ALL descendants
    var deleted = await context.Comments
        .Where(c => EF.Functions.Like(c.Path, $"{path}%"))
        .ExecuteDeleteAsync(ct);

logger.LogInformation("Deleted {Count} comments with path prefix {Path}", deleted, path);
}
```

### Flytta en underträd

Det är det dyra arbetet med materialiserade vägar - vi måste uppdatera alla efterföljande vägar

```csharp
public async Task MoveSubtreeAsync(
    int commentId,
    int newParentId,
    CancellationToken ct = default)
{
    await using var transaction = await context.Database.BeginTransactionAsync(ct);

try
    {
        // Get the node being moved
        var comment = await context.Comments
            .FirstOrDefaultAsync(c => c.Id == commentId, ct);

if (comment == null)
            throw new InvalidOperationException($"Comment {commentId} not found");

// Get the new parent
        var newParent = await context.Comments
            .FirstOrDefaultAsync(c => c.Id == newParentId, ct);

if (newParent == null)
            throw new InvalidOperationException($"New parent {newParentId} not found");

// Prevent cycles: can't move under own descendant
        if (newParent.Path.StartsWith(comment.Path))
        {
            throw new InvalidOperationException("Cannot move a node under its own descendant");
        }

var oldPath = comment.Path;
        var newPath = $"{newParent.Path}{comment.Id}/";

// Get all descendants (including the node itself)
        var descendants = await context.Comments
            .Where(c => EF.Functions.Like(c.Path, $"{oldPath}%"))
            .ToListAsync(ct);

// Update all paths by replacing the old prefix with the new one
        foreach (var descendant in descendants)
        {
            // Replace old path prefix with new one
            // Old: /1/3/7/  Node 7 moving under /2/
            // Node 7: /1/3/7/ -> /2/7/
            // Node 9 (child of 7): /1/3/7/9/ -> /2/7/9/
            descendant.Path = newPath + descendant.Path.Substring(oldPath.Length);
        }

// Update the direct parent reference
        comment.ParentCommentId = newParentId;

await context.SaveChangesAsync(ct);
        await transaction.CommitAsync(ct);

logger.LogInformation("Moved subtree of {Count} nodes from {OldPath} to {NewPath}",
            descendants.Count, oldPath, newPath);
    }
    catch
    {
        await transaction.RollbackAsync(ct);
        throw;
    }
}
```

## Frågaflödet visualisering

```mermaid
sequenceDiagram
    participant App as Application
    participant EF as EF Core
    participant DB as PostgreSQL

Note over App,DB: Getting Ancestors (Path parsing)
 App->>EF: GetAncestorsAsync(commentId)
 EF->>DB: SELECT path FROM comments WHERE id = @id
 DB-->>EF: Path "/1/3/7/"
 Note over App: Parse path → [1, 3]
 EF->>DB: SELECT * FROM comments WHERE id IN (1, 3)
 DB-->>EF: Ancestor comments
 EF-->>App: List<Comment>

Note over App,DB: Getting Descendants (LIKE query)
 App->>EF: GetDescendantsAsync(commentId)
 EF->>DB: SELECT path FROM comments WHERE id = @id
 DB-->>EF: Path "/1/3/"
 EF->>DB: SELECT * FROM comments WHERE path LIKE '/1/3/%'
 DB-->>EF: All descendants
 EF-->>App: List<Comment>
```

## Förmågor och egenskaper

| Operation | | | Complexitet || | Databas क्वäre |
|-----------|------------|------------------|-------|
| Insert | O(1) |
| få barn | O(1) | ♫ ♫ 1 | ♫ Use ParentCommentId index
| Ta förfäderna | OdM SK3 ♫ | ♫ ♫2 ♫
| skaffa barnbarn | OM SK2* | ♫ 2 ♫ ♫| ♫ Fetch path ♫
| Flytta underträdet ♫ | ♫ O ♫ ( ♫ s ♫ МSK3 ♫
| Lösa underträdet | OM SK2* | ♫ 2 ♫ ♫| ♫ Fetch path ♫

*Med rätt index på vägs colonn

## Inriktningsfaktorer

Pathindexet är kritiskt. För PostgreSQL, tänk på att använda [`text_pattern_ops`](https://www.postgresql.org/docs/current/indexes-opclass.html), som möjliggör effektiva prefix LIKE queries i icke-

```sql
-- Standard B-tree index (works for LIKE 'prefix%')
CREATE INDEX ix_comments_path ON comments (path);

-- Better for pattern matching in PostgreSQL
CREATE INDEX ix_comments_path_pattern ON comments (path text_pattern_ops);
```

Lägg detta via en migration:

```csharp
protected override void Up(MigrationBuilder migrationBuilder)
{
    migrationBuilder.Sql(
        "CREATE INDEX ix_comments_path_pattern ON comments (path text_pattern_ops)");
}
```

## Formateringsaspekter

Skillnade avgränsare har handel

| Format | | | Example || | Fördelen |
|--------|---------|------|------|
| `/1/3/7/` | Den här artikeln ♫ | ♫ Klara ♫ , ♫ URL ♫- ♫ likt ♫ , ♫ enkelt att analysera ♪ | ♫ Tar mer utrymme ♫
| `1.3.7` | PostgreSQLs ltree-stil | Kompakta | , | fungerar med ltree ♫ | ♫ Tidskonflikter med decimaler ♫
| `1,3,7` | KommaM SK1 Separerad | Enkel | Kommar i data kan orsaka problem M|
| `001.003.007` | FixeradM SK1bredd | Sortierbar, konsekvent | Limits ID-värde , avfallsyta |

Den `/id/` format med ledande och efterföljande skivor är tillförlitligt eftersom:

1. LIKE-mönster fungerar korrekt (`/1/%` matchar `/1/` men inte `/10/`)
2. Enkelt att dela och analysera
3. Människor- läsbar för debugging

## För och mot

| Fördelen | Motsägelser |
|------|------|
| Förfäder tillgängliga genom att analysera | | ( | ingen fråga | ) | МSK3 | Att flytta subträd kräver att uppdatera alla avkomma |
| Descendants via enkel LIKE-fråga | Längslängden begränsar trädbredd
| Depth calculable from path | String manipulation has overhead
| Människo - läsbar för att debugera ♫ ♫ | ♫ LIKE-fragen kan vara långsamma utan rätt index ♫
| Bra för brödkrummens skapande
| Single column addition | | | Kan | ' | inte använda standard B | МSK3 | trä för suffix matching |

## När man ska använda materialiserad väg

**Välj Materialiserad väg när:**

- Broadcrumbs är ett vanligt krav
- Förfäderna frågas oftare än ättlingarna
- Dröngens djup är begränsad ( du vinner ' du har inte 100+ nivåträd )
- Att flytta småträd är ovanligt
- Du vill ha mänskliga, -, läsbara hierarkiska data för att debugera

**undvika materialiserad väg när:**

- Du flyttar ofta subträd ( att uppdatera alla vägar är dyrt
- Träd kan vara väldigt djupa.
- Du behöver ett effektivt suffix matching ( att hitta alla träd som slutar i en mönster
- Du är mer bekväm med ltree.

## jämförelse med ltree

Om du är på PostgreSQL [Del 1.5: ltree](/blog/efcore-hierarchical-data-ltree) istället. ltree är i grund och botten en databas,

- GiST-index stöd för effektiva queryer
- Integrerade operatörer -`@>`, `<@`, `~`, etcM SK1
- Path-manipulationsfunktionen
- Pattern som matchar wildcards

Börsen är PostgreSQL-lock, - i . [Npgsql-provider supporterar nu LINQ-översättningar](https://www.npgsql.org/efcore/mapping/translations.html#ltree-functions) för ltree via `LTree` typ, fast rekursiv CTE kräver fortfarande rå SQL

## Seri Navigation

- [Del 1: Übersicht](/blog/efcore-hierarchical-data)
- [Del 1.1: Närliggande lista](/blog/efcore-hierarchical-data-adjacency)
- [Del 1.2: Slutbrädan](/blog/efcore-hierarchical-data-closure)
- **Del 1.3: Materialiserad väg** (den här artikeln )
- [Del 1.4: Nested Sets](/blog/efcore-hierarchical-data-nested)
- [Del 1.5: ltree](/blog/efcore-hierarchical-data-ltree)

This is a preview from the server running through my markdig pipeline

EF Hierarchies Entity Framework PostgreSQL

Datahierarkier Part 1.3: Materialiserad väg med EF Core

Saturday, 06 December 2025

Materialiserade vägar lagrar den kompletta ursprunget som en avgränsad sträng - som /1/3/7/ - gör förfäder omedelbart läsbara utan några anknytningar . Perfekt för brödkrummens skapande och människan

Del 1: Übersicht - Inleiding och jämförelse
Del 1.1: Närliggande lista
Del 1.2: Slutbrädan
Del 1.3: Materialiserad väg (den här artikeln )
Del 1.4: Nested Sets
Del 1.5: ltree

Vad är en materialiserad väg?

Materialiserad vägsmönster ( kallas också "Tålberäkningen" i Joe Celko, MSK: s träd och hierarkier) sparar den kompletta ursprunget till varje nod som en avgränsad sträng | - | som ett filepath eller postaladress |. | Istället för att spara bara | " | min moder är nod | МSK4 | sparar vi | |

Tänk på det som att lagra hela URL istället för bara sidans namn. vägen /blog/posts/2024/my-article talar om exakt var du är i hierarkin

Nyckelinsikten: Vi' är affärskrångliga sökningar för storvarad överskott . Förfäderna är denormaliserade in i varje rad, men detta gör förfädernas sökningar triviala.

Konceptet visualiserat

flowchart TD
    subgraph "Comment Tree"
        C1["Comment 1<br/>Path: /1/"]
        C2["Comment 2<br/>Path: /1/2/"]
        C3["Comment 3<br/>Path: /1/3/"]
        C4["Comment 4<br/>Path: /1/3/4/"]
    end

    C1 --> C2
    C1 --> C3
    C3 --> C4

    subgraph "What the paths tell us"
        P1["Comment 4's path /1/3/4/ means:<br/>• Ancestors are 1, 3 (parse the path)<br/>• Depth is 3 (count separators - 1)<br/>• Root is 1 (first element)"]
    end

    style C1 stroke:#6366f1,stroke-width:2px
    style C2 stroke:#8b5cf6,stroke-width:2px
    style C3 stroke:#8b5cf6,stroke-width:2px
    style C4 stroke:#a855f7,stroke-width:2px

Pathen är själv

Att läsa förfäder: Förefatta /1/3/4/ → förfäder är [1, 3, 4]
Att hitta barnbarn: Fråga WHERE path LIKE '/1/3/%' → får allt under noden 3
Beräkning av djupet: räkna separatorna minus ett
Att hitta syskon: Fråga WHERE path LIKE '/1/3/_/' (medelbara barn av 3)

Enhetens definition

Enheten lägger till en enda vägs kolumn:

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; }

    public int PostId { get; set; }
    public BlogPost Post { get; set; } = null!;

    // ========== MATERIALISED PATH ==========

    // The complete path from root to this node
    // Format: /ancestor1/ancestor2/.../thisNode/
    // Examples:
    //   Root comment: "/1/"
    //   Child of 1: "/1/5/"
    //   Grandchild: "/1/5/12/"
    //
    // The leading and trailing slashes make pattern matching easier:
    // - LIKE '/1/%' finds all descendants of 1 (includes /1/ itself)
    // - LIKE '/1/5/%' finds all descendants of 5 under 1
    public string Path { get; set; } = string.Empty;

    // We still keep ParentCommentId for:
    // 1. Quick "who is my parent" without parsing
    // 2. EF Core navigation properties
    // 3. Data integrity (can validate path matches parent relationship)
    public int? ParentCommentId { get; set; }
    public Comment? ParentComment { get; set; }
    public ICollection<Comment> Children { get; set; } = new List<Comment>();

    // ========== COMPUTED HELPERS ==========

    // Parse ancestors from path - not stored, computed on demand
    public IEnumerable<int> GetAncestorIds()
    {
        if (string.IsNullOrEmpty(Path)) yield break;

        // Split "/1/3/4/" into ["", "1", "3", "4", ""]
        var parts = Path.Split('/', StringSplitOptions.RemoveEmptyEntries);

        // Return all except the last (which is this node's ID)
        for (int i = 0; i < parts.Length - 1; i++)
        {
            if (int.TryParse(parts[i], out var id))
                yield return id;
        }
    }

    // Calculate depth from path
    public int GetDepth()
    {
        if (string.IsNullOrEmpty(Path)) return 0;
        // Count segments: "/1/3/4/" has 3 segments, depth is 2 (0-indexed from root)
        return Path.Split('/', StringSplitOptions.RemoveEmptyEntries).Length - 1;
    }
}

EF Core Konfiguration

public class CommentConfiguration : IEntityTypeConfiguration<Comment>
{
    public void Configure(EntityTypeBuilder<Comment> builder)
    {
        builder.HasKey(c => c.Id);

        builder.Property(c => c.Content)
            .IsRequired()
            .HasMaxLength(10000);

        builder.Property(c => c.Author)
            .IsRequired()
            .HasMaxLength(200);

        // ========== PATH COLUMN ==========
        // Set a reasonable max length - this limits your tree depth
        // /1/12345/12346/12347/...
        // Each segment is up to ~7 chars (ID + slash), so 1000 chars ≈ 140 levels
        builder.Property(c => c.Path)
            .IsRequired()
            .HasMaxLength(1000);

        // Relationship to blog post
        builder.HasOne(c => c.Post)
            .WithMany(p => p.Comments)
            .HasForeignKey(c => c.PostId)
            .OnDelete(DeleteBehavior.Cascade);

        // Self-referencing (optional but useful)
        builder.HasOne(c => c.ParentComment)
            .WithMany(c => c.Children)
            .HasForeignKey(c => c.ParentCommentId)
            .OnDelete(DeleteBehavior.Restrict);

        // ========== INDEXES ==========

        // Standard indexes
        builder.HasIndex(c => c.PostId);
        builder.HasIndex(c => c.ParentCommentId);

        // PATH INDEX - Critical for performance!
        // This makes LIKE 'prefix%' queries efficient
        // PostgreSQL can use a B-tree index for prefix LIKE patterns
        // (but NOT for '%suffix' or '%contains%' patterns)
        builder.HasIndex(c => c.Path);

        // For PostgreSQL, a text_pattern_ops index is even better for LIKE:
        // CREATE INDEX ix_comments_path ON comments (path text_pattern_ops);
        // You may want to add this via a raw migration
    }
}

Databaseringsschema

erDiagram
    COMMENT {
        int id PK
        string content
        string author
        datetime created_at
        int post_id FK
        int parent_comment_id FK "optional"
        string path "e.g. /1/3/7/"
    }

    BLOG_POST {
        int id PK
        string title
        string content
    }

    BLOG_POST ||--o{ COMMENT : "has"
    COMMENT ||--o{ COMMENT : "parent-child"

Operationer

Insert a New Comment

Inseration kräver att bygga vägen från moderen

public async Task<Comment> AddCommentAsync(
    int postId,
    int? parentId,
    string author,
    string content,
    CancellationToken ct = default)
{
    string path;

    if (parentId.HasValue)
    {
        // Get parent's path to extend it
        var parentPath = await context.Comments
            .Where(c => c.Id == parentId.Value)
            .Select(c => c.Path)
            .FirstOrDefaultAsync(ct);

        if (parentPath == null)
        {
            throw new InvalidOperationException($"Parent comment {parentId} not found");
        }

        // We need the ID first, so we'll update the path after saving
        // (Chicken-and-egg: path contains our ID, but we don't have ID until saved)

        var comment = new Comment
        {
            PostId = postId,
            ParentCommentId = parentId,
            Author = author,
            Content = content,
            CreatedAt = DateTime.UtcNow,
            Path = string.Empty  // Temporary - will update after save
        };

        context.Comments.Add(comment);
        await context.SaveChangesAsync(ct);

        // Now we have the ID - build the real path
        // Parent path "/1/3/" + our ID "7" = "/1/3/7/"
        comment.Path = $"{parentPath}{comment.Id}/";
        await context.SaveChangesAsync(ct);

        logger.LogInformation("Added comment {CommentId} with path {Path}", comment.Id, comment.Path);
        return comment;
    }
    else
    {
        // Root comment - path is just our ID
        var comment = new Comment
        {
            PostId = postId,
            ParentCommentId = null,
            Author = author,
            Content = content,
            CreatedAt = DateTime.UtcNow,
            Path = string.Empty  // Temporary
        };

        context.Comments.Add(comment);
        await context.SaveChangesAsync(ct);

        comment.Path = $"/{comment.Id}/";
        await context.SaveChangesAsync(ct);

        logger.LogInformation("Added root comment {CommentId} with path {Path}", comment.Id, comment.Path);
        return comment;
    }
}

få omedelbart barn

Att använda moderen- relation till barn ( vi behöll moderKommentid för bekvämlighet ):

public async Task<List<Comment>> GetChildrenAsync(int commentId, CancellationToken ct = default)
{
    // Option 1: Use ParentCommentId (simple, always works)
    return await context.Comments
        .AsNoTracking()
        .Where(c => c.ParentCommentId == commentId)
        .OrderBy(c => c.CreatedAt)
        .ToListAsync(ct);

    // Option 2: Use path pattern (demonstrates path power)
    // var parentPath = await context.Comments
    //     .Where(c => c.Id == commentId)
    //     .Select(c => c.Path)
    //     .FirstOrDefaultAsync(ct);
    //
    // if (parentPath == null) return new List<Comment>();
    //
    // // Find paths that extend parent by exactly one segment
    // // Parent: /1/3/  Children: /1/3/X/ where X is one number
    // var childPathPattern = $"{parentPath}%";
    //
    // return await context.Comments
    //     .AsNoTracking()
    //     .Where(c => EF.Functions.Like(c.Path, childPathPattern)
    //              && c.Path != parentPath
    //              && c.ParentCommentId == commentId)  // Ensures immediate children only
    //     .ToListAsync(ct);
}

få alla förfäder

Det är här som materialiserade vägar skiner - analysera vägen , inga datauppsök behöver göras

public async Task<List<Comment>> GetAncestorsAsync(int commentId, CancellationToken ct = default)
{
    // Step 1: Get the path (single query)
    var path = await context.Comments
        .Where(c => c.Id == commentId)
        .Select(c => c.Path)
        .FirstOrDefaultAsync(ct);

    if (string.IsNullOrEmpty(path))
        return new List<Comment>();

    // Step 2: Parse ancestor IDs from path
    // Path "/1/3/7/" -> split -> ["1", "3", "7"] -> take all but last -> [1, 3]
    var ancestorIds = path
        .Split('/', StringSplitOptions.RemoveEmptyEntries)
        .SkipLast(1)  // Exclude self
        .Select(int.Parse)
        .ToList();

    if (!ancestorIds.Any())
        return new List<Comment>();

    // Step 3: Fetch ancestors (single query, uses primary key index)
    var ancestors = await context.Comments
        .AsNoTracking()
        .Where(c => ancestorIds.Contains(c.Id))
        .ToListAsync(ct);

    // Step 4: Order by position in path (root first)
    return ancestorIds
        .Select(id => ancestors.First(a => a.Id == id))
        .ToList();
}

få alla barnbarn

Använd LIKE med prefixet path:

public async Task<List<Comment>> GetDescendantsAsync(int commentId, CancellationToken ct = default)
{
    // Get the path first
    var path = await context.Comments
        .Where(c => c.Id == commentId)
        .Select(c => c.Path)
        .FirstOrDefaultAsync(ct);

    if (string.IsNullOrEmpty(path))
        return new List<Comment>();

    // LIKE 'path%' finds all paths that START with this path
    // Path "/1/3/" matches "/1/3/", "/1/3/5/", "/1/3/5/9/", etc.
    // Using EF.Functions.Like for proper SQL generation
    return await context.Comments
        .AsNoTracking()
        .Where(c => EF.Functions.Like(c.Path, $"{path}%") && c.Id != commentId)
        .OrderBy(c => c.Path)  // Gives us depth-first order!
        .ToListAsync(ct);
}

få barnbarn med djup

Vi kan räkna ut djupet från vägen:

public async Task<List<CommentWithDepth>> GetDescendantsWithDepthAsync(
    int commentId,
    int? maxDepth = null,
    CancellationToken ct = default)
{
    var comment = await context.Comments
        .AsNoTracking()
        .FirstOrDefaultAsync(c => c.Id == commentId, ct);

    if (comment == null)
        return new List<CommentWithDepth>();

    var basePath = comment.Path;
    var baseDepth = basePath.Split('/', StringSplitOptions.RemoveEmptyEntries).Length;

    // Get all descendants
    var query = context.Comments
        .AsNoTracking()
        .Where(c => EF.Functions.Like(c.Path, $"{basePath}%") && c.Id != commentId);

    var descendants = await query.ToListAsync(ct);

    // Calculate relative depth and filter if needed
    var result = descendants
        .Select(d =>
        {
            var absoluteDepth = d.Path.Split('/', StringSplitOptions.RemoveEmptyEntries).Length;
            var relativeDepth = absoluteDepth - baseDepth;
            return new CommentWithDepth
            {
                Id = d.Id,
                Content = d.Content,
                Author = d.Author,
                CreatedAt = d.CreatedAt,
                PostId = d.PostId,
                ParentCommentId = d.ParentCommentId,
                Path = d.Path,
                Depth = relativeDepth
            };
        })
        .Where(d => !maxDepth.HasValue || d.Depth <= maxDepth.Value)
        .OrderBy(d => d.Path)
        .ToList();

    return result;
}

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 string Path { get; set; } = string.Empty;
    public int Depth { get; set; }
}

Lösa ett underträd

Enkel med vägsmatchning:

public async Task DeleteSubtreeAsync(int commentId, CancellationToken ct = default)
{
    var path = await context.Comments
        .Where(c => c.Id == commentId)
        .Select(c => c.Path)
        .FirstOrDefaultAsync(ct);

    if (string.IsNullOrEmpty(path))
    {
        throw new InvalidOperationException($"Comment {commentId} not found");
    }

    // Delete all comments whose path starts with this path
    // This includes the comment itself and ALL descendants
    var deleted = await context.Comments
        .Where(c => EF.Functions.Like(c.Path, $"{path}%"))
        .ExecuteDeleteAsync(ct);

    logger.LogInformation("Deleted {Count} comments with path prefix {Path}", deleted, path);
}

Flytta en underträd

Det är det dyra arbetet med materialiserade vägar - vi måste uppdatera alla efterföljande vägar

public async Task MoveSubtreeAsync(
    int commentId,
    int newParentId,
    CancellationToken ct = default)
{
    await using var transaction = await context.Database.BeginTransactionAsync(ct);

    try
    {
        // Get the node being moved
        var comment = await context.Comments
            .FirstOrDefaultAsync(c => c.Id == commentId, ct);

        if (comment == null)
            throw new InvalidOperationException($"Comment {commentId} not found");

        // Get the new parent
        var newParent = await context.Comments
            .FirstOrDefaultAsync(c => c.Id == newParentId, ct);

        if (newParent == null)
            throw new InvalidOperationException($"New parent {newParentId} not found");

        // Prevent cycles: can't move under own descendant
        if (newParent.Path.StartsWith(comment.Path))
        {
            throw new InvalidOperationException("Cannot move a node under its own descendant");
        }

        var oldPath = comment.Path;
        var newPath = $"{newParent.Path}{comment.Id}/";

        // Get all descendants (including the node itself)
        var descendants = await context.Comments
            .Where(c => EF.Functions.Like(c.Path, $"{oldPath}%"))
            .ToListAsync(ct);

        // Update all paths by replacing the old prefix with the new one
        foreach (var descendant in descendants)
        {
            // Replace old path prefix with new one
            // Old: /1/3/7/  Node 7 moving under /2/
            // Node 7: /1/3/7/ -> /2/7/
            // Node 9 (child of 7): /1/3/7/9/ -> /2/7/9/
            descendant.Path = newPath + descendant.Path.Substring(oldPath.Length);
        }

        // Update the direct parent reference
        comment.ParentCommentId = newParentId;

        await context.SaveChangesAsync(ct);
        await transaction.CommitAsync(ct);

        logger.LogInformation("Moved subtree of {Count} nodes from {OldPath} to {NewPath}",
            descendants.Count, oldPath, newPath);
    }
    catch
    {
        await transaction.RollbackAsync(ct);
        throw;
    }
}

Frågaflödet visualisering

sequenceDiagram
    participant App as Application
    participant EF as EF Core
    participant DB as PostgreSQL

    Note over App,DB: Getting Ancestors (Path parsing)
    App->>EF: GetAncestorsAsync(commentId)
    EF->>DB: SELECT path FROM comments WHERE id = @id
    DB-->>EF: Path "/1/3/7/"
    Note over App: Parse path → [1, 3]
    EF->>DB: SELECT * FROM comments WHERE id IN (1, 3)
    DB-->>EF: Ancestor comments
    EF-->>App: List<Comment>

    Note over App,DB: Getting Descendants (LIKE query)
    App->>EF: GetDescendantsAsync(commentId)
    EF->>DB: SELECT path FROM comments WHERE id = @id
    DB-->>EF: Path "/1/3/"
    EF->>DB: SELECT * FROM comments WHERE path LIKE '/1/3/%'
    DB-->>EF: All descendants
    EF-->>App: List<Comment>

Förmågor och egenskaper

Operation			Complexitet
Insert	O(1)
få barn	O(1)	♫ ♫ 1	♫ Use ParentCommentId index
Ta förfäderna	OdM SK3 ♫	♫ ♫2 ♫
skaffa barnbarn	OM SK2*	♫ 2 ♫ ♫	♫ Fetch path ♫
Flytta underträdet ♫	♫ O ♫ ( ♫ s ♫ МSK3 ♫
Lösa underträdet	OM SK2*	♫ 2 ♫ ♫	♫ Fetch path ♫

*Med rätt index på vägs colonn

Inriktningsfaktorer

Pathindexet är kritiskt. För PostgreSQL, tänk på att använda text_pattern_ops, som möjliggör effektiva prefix LIKE queries i icke-

-- Standard B-tree index (works for LIKE 'prefix%')
CREATE INDEX ix_comments_path ON comments (path);

-- Better for pattern matching in PostgreSQL
CREATE INDEX ix_comments_path_pattern ON comments (path text_pattern_ops);

Lägg detta via en migration:

protected override void Up(MigrationBuilder migrationBuilder)
{
    migrationBuilder.Sql(
        "CREATE INDEX ix_comments_path_pattern ON comments (path text_pattern_ops)");
}

Formateringsaspekter

Skillnade avgränsare har handel

Format			Example
`/1/3/7/`	Den här artikeln ♫	♫ Klara ♫ , ♫ URL ♫- ♫ likt ♫ , ♫ enkelt att analysera ♪	♫ Tar mer utrymme ♫
`1.3.7`	PostgreSQLs ltree-stil	Kompakta	,	fungerar med ltree ♫	♫ Tidskonflikter med decimaler ♫
`1,3,7`	KommaM SK1 Separerad	Enkel	Kommar i data kan orsaka problem M
`001.003.007`	FixeradM SK1bredd	Sortierbar, konsekvent	Limits ID-värde , avfallsyta

Den /id/ format med ledande och efterföljande skivor är tillförlitligt eftersom:

LIKE-mönster fungerar korrekt (/1/% matchar /1/ men inte /10/)
Enkelt att dela och analysera
Människor- läsbar för debugging

För och mot

Fördelen	Motsägelser
Förfäder tillgängliga genom att analysera		(	ingen fråga	)	МSK3	Att flytta subträd kräver att uppdatera alla avkomma
Descendants via enkel LIKE-fråga	Längslängden begränsar trädbredd
Depth calculable from path	String manipulation has overhead
Människo - läsbar för att debugera ♫ ♫	♫ LIKE-fragen kan vara långsamma utan rätt index ♫
Bra för brödkrummens skapande
Single column addition			Kan	'	inte använda standard B	МSK3	trä för suffix matching

När man ska använda materialiserad väg

Välj Materialiserad väg när:

Broadcrumbs är ett vanligt krav
Förfäderna frågas oftare än ättlingarna
Dröngens djup är begränsad ( du vinner ' du har inte 100+ nivåträd )
Att flytta småträd är ovanligt
Du vill ha mänskliga, -, läsbara hierarkiska data för att debugera

undvika materialiserad väg när:

Du flyttar ofta subträd ( att uppdatera alla vägar är dyrt
Träd kan vara väldigt djupa.
Du behöver ett effektivt suffix matching ( att hitta alla träd som slutar i en mönster
Du är mer bekväm med ltree.

jämförelse med ltree

Om du är på PostgreSQL Del 1.5: ltree istället. ltree är i grund och botten en databas,

GiST-index stöd för effektiva queryer
Integrerade operatörer -@>, <@, ~, etcM SK1
Path-manipulationsfunktionen
Pattern som matchar wildcards

Börsen är PostgreSQL-lock, - i . Npgsql-provider supporterar nu LINQ-översättningar för ltree via LTree typ, fast rekursiv CTE kräver fortfarande rå SQL

Del 1: Übersicht
Del 1.1: Närliggande lista
Del 1.2: Slutbrädan
Del 1.3: Materialiserad väg (den här artikeln )
Del 1.4: Nested Sets
Del 1.5: ltree