Deployed dd99267 with MkDocs version: 1.6.1

arkitektur/materialisering/index.html

@@ -1201,16 +1201,24 @@
 <h1 id="materialiseringsstrategier">Materialiseringsstrategier<a class="headerlink" href="#materialiseringsstrategier" title="Permanent link">&para;</a></h1>
 <p><a href="https://docs.getdbt.com/docs/build/materializations">Hva er materialiseringer i dbt?</a>. dbt-oracle støtter alle former for materialisering.</p>
 <p>Generelt er det en god ide å følge <a href="https://docs.getdbt.com/best-practices/materializations/5-best-practices">Best practices for materializations</a> fra dbt labs.</p>
-<p>Det er likevel noen avvik:
-1. Staging modeller bør hovedsakelig være views.
-    - Men pseduonymisering skal skje så tidlig som mulig, og derfor er det nødvendig at kilder som inneholder personnøkler blir lastet inkrementelt. Det er ofte et krav om at rådata blir slettet etter 6 måneder.
-2. Intermediate ved kompleks logikk. Kjør views når du kan. Når views går for tregt, har du tre valg:
-    1. Kjøre table materialiseringer. tabeller blir droppet, purget og rekjørt med alt innhold fra spørringen i modellfilen. Ikke lurt ved ved større mengder data, både ytelsesmessig og lagring i flere lag.
-    2. Incrememental. Tabellen bevares og nye endrede rader blir lagt til med merge.
-    3. Delta last med table models ... trenger POC
-3. Marts skal være stabil. Det er her alle spørringer fra konsumenter kjøres, og det er viktig for basen å opparbeide statistikk på spørringer som kjører ofte.
-    - materialized_view er for MVP og små datamengder, jher er ikke ytelse noe problem.
-    - For løsninger med større datamenger, kjør inkrementell last med partisjonering og indeksering.</p>
+<p>Det er likevel noen avvik:</p>
+<ol>
+<li>Staging modeller bør hovedsakelig være views.<ul>
+<li>Men pseduonymisering skal skje så tidlig som mulig, og derfor er det nødvendig at kilder som inneholder personnøkler blir lastet inkrementelt. Det er ofte et krav om at rådata blir slettet etter 6 måneder.</li>
+</ul>
+</li>
+<li>Intermediate ved kompleks logikk. Kjør views når du kan. Når views går for tregt, har du tre valg:<ol>
+<li>Kjøre table materialiseringer. tabeller blir droppet, purget og rekjørt med alt innhold fra spørringen i modellfilen. Ikke lurt ved ved større mengder data, både ytelsesmessig og lagring i flere lag.</li>
+<li>Incrememental. Tabellen bevares og nye endrede rader blir lagt til med merge.</li>
+<li>Delta last med table models ... trenger POC</li>
+</ol>
+</li>
+<li>Marts skal være stabil. Det er her alle spørringer fra konsumenter kjøres, og det er viktig for basen å opparbeide statistikk på spørringer som kjører ofte.<ul>
+<li>materialized_view er for MVP og små datamengder, jher er ikke ytelse noe problem.</li>
+<li>For løsninger med større datamenger, kjør inkrementell last med partisjonering og indeksering. </li>
+</ul>
+</li>
+</ol>