# Data-hiërarchieën Deel 1.3: Gematerialiseerd pad met EF-kern
2025-12-06T09:30
Gematerialiseerde paden slaan de volledige afstamming op als een begrensde tekenreeks - zoals `/1/3/7/` Perfect voor broodkruimels generatie en menselijk leesbare debuggen, hoewel bewegende subbomen betekent het bijwerken van elke afstammeling pad string.
## Serienavigatie
- [Deel 1: Overzicht](/blog/efcore-hierarchical-data) - Inleiding en vergelijking
- [Deel 1.1: Adjacentielijst](/blog/efcore-hierarchical-data-adjacency)
- [Deel 1.2: Sluitingstabel](/blog/efcore-hierarchical-data-closure)
- **Deel 1.3: Gematerialiseerd pad** (dit artikel)
- [Deel 1.4: Nested Sets](/blog/efcore-hierarchical-data-nested)
- [Deel 1.5: ltree](/blog/efcore-hierarchical-data-ltree)
---
## Wat is een gematerialiseerd pad?
Het gematerialiseerde padpatroon (ook wel "padnummering" genoemd) in [Joe Celko's Bomen en Hiërarchieën](https://www.amazon.com/Hierarchies-Smarties-Kaufmann-Management-Systems/dp/0123877334)) slaat de volledige voorgeschiedenis van elk knooppunt op als een afgebakend tekenreeks - zoals een bestandspad of postadres. In plaats van "mijn ouder is knooppunt 5" op te slaan, slaan we "Ik ben bereikt via knooppunten 1 → 3 → 5 → 7" direct in de rij.
Zie het als het opslaan van de volledige URL in plaats van alleen de paginanaam. `/blog/posts/2024/my-article` vertelt je precies waar je bent in de hiërarchie, geen opzoekingen nodig.
**Belangrijkste inzicht:** We ruilen query complexiteit voor opslag redundantie. De voorouders worden gedenormaliseerd in elke rij, maar dit maakt voorouder vragen triviaal - gewoon parse de string.
[TOC]
## Het concept gevisualiseerd
```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
```
Het pad is zelfbeschrijvend:
- **Lezende voorouders:** Ontleden `/1/3/4/` → voorouders zijn [1, 3, 4]
- **Afstammelingen vinden:** Opvragen `WHERE path LIKE '/1/3/%'` → krijgt alle onder knooppunt 3
- **Berekendiepte:** Tel de scheidingstekens min één
- **Het vinden van broers en zussen:** Opvragen `WHERE path LIKE '/1/3/_/'` (onmiddellijke kinderen van 3)
## Entiteitsdefinitie
De entiteit voegt één kolom Pad toe:
```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 Children { get; set; } = new List();
// ========== COMPUTED HELPERS ==========
// Parse ancestors from path - not stored, computed on demand
public IEnumerable 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-kernconfiguratie
```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);
// ========== 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
}
}
```
## Databaseschema
```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"
```
## Operaties
### Nieuwe opmerking invoegen
Invoegen vereist het bouwen van het pad vanaf het pad van de ouder:
```csharp
public async Task 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;
}
}
```
### Onmiddellijke kinderen ophalen
Met behulp van de ouder-kind relatie (we hielden ParentCommentId voor het gemak):
```csharp
public async Task> 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();
//
// // 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);
}
```
### Alle voorouders ophalen
Dit is waar gematerialiseerde paden schijnen - ontleden het pad, geen database opzoeken nodig:
```csharp
public async Task> 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();
// 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();
// 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();
}
```
### Alle afstammelingen ophalen
Gebruik LIKE met het padprefix:
```csharp
public async Task> 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();
// 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);
}
```
### Afstammelingen met diepte ophalen
We kunnen diepte berekenen vanaf het pad:
```csharp
public async Task> 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();
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; }
}
```
### Een subboom verwijderen
Eenvoudig met pad dat bijpassend is:
```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);
}
```
### Een subboom verplaatsen
Dit is de dure operatie voor gematerialiseerde paden - we moeten ALLE afstammelingen bijwerken:
```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;
}
}
```
## Query Flow Visualisatie
```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
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
```
## Prestatiekenmerken
Operatie Complexiteit Database Queries Notes
|-----------|------------|------------------|-------|
* Invoegen * O(1) * 2 * Invoegen + update pad *
* Get children * * O(1) * 1 * Gebruik ParentCommentId index *
Get get voorvaderen O(d) 2 Fetch path + fetch d voorvaderen
Krijg afstammelingen O(1)* Haal het pad + LIKE query
Move subtree O(s) 1 Update s afstammeling paden
Delete subtree O(1)* Haal pad + bulk delete
*Met juiste index op padkolom
## Indexoverwegingen
De padindex is cruciaal. Voor PostgreSQL, overwegen het gebruik van [`text_pattern_ops`](https://www.postgresql.org/docs/current/indexes-opclass.html), die efficiënte voorvoegsel LIKE queries in niet-C locales mogelijk maakt:
```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);
```
Voeg dit toe via een migratie:
```csharp
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.Sql(
"CREATE INDEX ix_comments_path_pattern ON comments (path text_pattern_ops)");
}
```
## Padopmaak-overwegingen
Verschillende afbakeningen hebben trade-offs:
Formaat Voorbeeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
|--------|---------|------|------|
| `/1/3/7/` Dit artikel is duidelijk, URL-achtig, eenvoudig te verwerken . Gebruikt meer ruimte .
| `1.3.7` PostgreSQL ltree stijl Compact, werkt met ltree
| `1,3,7` Gescheiden door komma's Eenvoudige Comma in data kan problemen veroorzaken
| `001.003.007` Sorteerbaar, consistent en beperkt het ID-bereik, afvalruimte
De `/id/` formaat met leading en trailing slashes wordt aanbevolen omdat:
1. Soortgelijke patronen werken correct (`/1/%` lucifers `/1/` maar niet `/10/`)
2. Gemakkelijk te splitsen en te ontleden
3. Menselijk leesbaar voor debuggen
## Voors en tegens
Bedankt voor je hulp.
|------|------|
Voorouders beschikbaar door te ontleden (geen query) Bewegende subbomen vereist het updaten van alle afstammelingen
Afstammelingen via simpele LIKE query Padlengte grenzen boomdiepte
Diepte calculeerbaar vanaf pad . . String manipulatie heeft overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mensenleesbaar voor het debuggen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Goed voor broodkruimels generatie . . Pad moet worden gehouden in sync met ParentCommentId . .
Kan standaard B-boom voor achtervoegsel matching niet gebruiken
## Wanneer moet een gematerialiseerd pad worden gebruikt?
**Kies Gematerialiseerde Pad wanneer:**
- Broodkruimels zijn een gemeenschappelijke eis
- Voorvaderen worden vaker bevraagd dan afstammelingen.
- Boomdiepte is begrensd (je hebt geen 100+ niveau bomen)
- Bewegende subbomen is zeldzaam
- U wilt menselijk leesbare hiërarchiegegevens voor debuggen
**Vermijd gematerialiseerd pad wanneer:**
- U verplaatst vaak subbomen (bijwerken van alle paden is duur)
- Bomen kunnen zeer diep zijn (path strings worden onhandig)
- Je hebt efficiënte achtervoegsel matching nodig (het vinden van alle bomen eindigend in een patroon)
- U bent comfortabeler met ltree (PostgreSQL-specifiek maar meer geoptimaliseerd)
## Vergelijking met ltree
Als u op PostgreSQL, overwegen [Deel 1.5: ltree](/blog/efcore-hierarchical-data-ltree) ltree is in wezen een database-native, geoptimaliseerd gematerialiseerd pad met:
- GiST index ondersteuning voor efficiënte queries
- Ingebouwde exploitanten (`@>`, `<@`, `~`, enz.)
- Padmanipulatiefuncties
- Patroon dat overeenkomt met wildcards
De trade-off is PostgreSQL lock-in. Merk op dat de [Npgsql provider ondersteunt nu LINQ vertalingen](https://www.npgsql.org/efcore/mapping/translations.html#ltree-functions) voor ltree via de `LTree` type, hoewel recursieve CTE's nog steeds ruwe SQL nodig hebben.
## Serienavigatie
- [Deel 1: Overzicht](/blog/efcore-hierarchical-data)
- [Deel 1.1: Adjacentielijst](/blog/efcore-hierarchical-data-adjacency)
- [Deel 1.2: Sluitingstabel](/blog/efcore-hierarchical-data-closure)
- **Deel 1.3: Gematerialiseerd pad** (dit artikel)
- [Deel 1.4: Nested Sets](/blog/efcore-hierarchical-data-nested)
- [Deel 1.5: ltree](/blog/efcore-hierarchical-data-ltree)