En diskusjon om bruk av UUID (Universally Unique Identifier) som arkividentifikator iNikita Noark5 Coreversjon 0.9kan ta utgangspunkt i både tekniske og arkivfaglige vurderinger. Her er en strukturert gjennomgang av fordeler, ulemper og relevante hensyn:
🎯 Hva er en UUID? En UUID (f.eks.550e8400-e29b-41d4-a716-446655440000) er en 128-bit identifikator som er praktisk talt garantert å være unik, selv på tvers av systemer.
✅ Fordeler med UUID i Noark 5 Core 1.Global unikhet
* Sikrer at identifikatorer ikke kolliderer ved systemintegrasjon eller migrering.
* Gjør det mulig å referere til objekter på tvers av systemer og tid (f.eks. mellom organer, eksport/import). 2.Dekobling fra databaseimplementasjon
* UUID-er er uavhengige av interne sekvenser (f.eks. auto-increment id-er).
* Gir større fleksibilitet ved migrasjon, kopiering og distribuert utvikling. 3.Robusthet for asynkron behandling
* Ved f.eks. mottak av metadata eller filer i meldingskøer kan UUID-en genereres på forhånd og brukes som "anker". 4.Forberedt for skylagring og mikrotjenester
* I en mikrotjenestearkitektur eller skybasert løsning der flere komponenter opererer selvstendig, gjør UUID det enkelt å holde orden på entiteter.
⚠️ Ulemper og utfordringer 1.Lite menneskelesbart
* En UUID gir ingen informasjon om innhold, avsender eller rekkefølge.
* Kan gjøre manuell feilsøking og arkivfaglig tilsyn vanskeligere. 2.Større lagrings- og indekseringskostnader
* Sammenlignet med heltall (f.eks. 4 byte), bruker UUID mer plass og kan være tregere å indeksere i enkelte databaser. 3.Bryter med tradisjonelle arkivnøkler
* Tradisjonell arkivstruktur (arkiv, arkivdel, klasse, mappe, journalpost etc.) baserer seg på sekvensielle og hierarkiske nøkler. UUID bryter med dette. 4.Kompatibilitet med arkivplan og bevaringsstrategier
* Arkivfaglige krav fra Arkivverket og Riksarkivet fordrer ofte lesbare identifikatorer for langtidsbevaring og publisering.
🔄 Mulige kompromisser 🔹 Hybridmodell:
* Bruke UUID somintern primærnøkkeli databasen, men ha enmenneskelesbar arkivnøkkelsom sekundær identifikator (f.eks.2025/00023-J).
* UUID er med i REST-API og internt, men arkivnøkkel vises i brukergrensesnitt og eksport. 🔹 Mapping-tabeller:
* Lag separate tabeller som knytter UUID til arkivstruktur, for lettere søk og arkivfaglig behandling.
📚 Relevante referanser
* Noark 5-standardenbeskriver ikke eksplisitt UUID som krav, men åpner for fleksibilitet i implementasjoner.
* Arkivverketer opptatt av langtidsbevaring og lesbarhet, noe som taler for å ikke eksponere UUID direkte til arkivarer eller offentligheten.
🧩 Konklusjon Bruk av UUID som arkividentifikator i Nikita Noark5 Core er fornuftigteknisk sett, men kreverarkivfaglig bevissthet. En god løsning er åskille mellom teknisk identifikator (UUID)ogfaglig arkivnøkkel, og sikre at eksport og langtidslagring bevarer struktur og lesbarhet i tråd med arkivlovgivning.