From 61937acaffdf631e1820695a8d359c5ed0179ecc Mon Sep 17 00:00:00 2001 From: delmona Date: Sat, 19 Oct 2024 16:06:49 +0200 Subject: [PATCH] Litt mer fiks i dokumentasjonen for Spenns materialiseringsstrategi --- docs/arkitektur/materialisering_spenn.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/arkitektur/materialisering_spenn.md b/docs/arkitektur/materialisering_spenn.md index c89e82d..aebce01 100644 --- a/docs/arkitektur/materialisering_spenn.md +++ b/docs/arkitektur/materialisering_spenn.md @@ -6,7 +6,7 @@ Formålet med denne strategien er å unngå droppe og deretter opprette datavare |------------------|-------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | **Staging** | `ephemeral` | Staging-modellene blir materialisert som `ephemeral` fordi de kun fungerer som simple transformasjoner som ikke skal eksponeres for sluttbrukeren. Det er heller ikke behov for å lagre dataene fysisk. | | **Intermediate** | `view` | Intermediate-modellene blir materialisert som `view` fordi de har kompleks logikk og kjører ikke for tregt. | -| **Marts** | `incremental` og `view` | Faktatabeller og aggregater (både brede og åpne aggregater som skal deles og konsumeres) blir materialisert som hhv. `incremental` og `view`. Faktatabeller, som ofte inneholder store datamengder, blir materialisert som `incremental` for å redusere kjøre- og lagringstiden. Aggregater blir materialisert som `view`, og ikke som `incremental`, da de ikke inneholder mye data og mangler unike nøkler. Hvis aggregatene begynner å ta for lang tid å kjøre som `view`, kan de alternativt materialiseres som `incremental` (gitt at duplikater ikke er et problem for modellen og/eller at `unique_key` eksisterer) eller som `materialized view` (se utfordringer nevnt nedenfor). | +| **Marts** | `incremental` og `view` | Faktatabeller, som ofte inneholder store datamengder, blir materialisert som `incremental` for å redusere kjøre- og lagringstiden. Aggregater (både brede og åpne aggregater som skal deles og konsumeres) blir materialisert som `view` da de ikke inneholder mye data og mangler unike nøkler. Hvis aggregatene begynner å ta for lang tid å kjøre som `view`, kan de alternativt materialiseres som `incremental` (gitt at duplikater ikke er et problem for modellen og/eller at `unique_key` eksisterer) eller som `materialized view` (se utfordringer nevnt nedenfor). | ## Mer om vår incremental-materialisering i Marts