Il paradigma naturale in teoria per la memorizzazione di XBRL in un database sarebbe OLAP, perché XBRL riguarda i cubi di dati. OLAP in cima a un database relazionale sarebbe chiamato ROLAP.
Questo non è un problema banale, perché i fatti presi da un gran numero di tassonomie possono formare un cubo molto grande e sparso (per i depositi SEC ha dimensioni 10k+), e anche perché la creazione di uno schema SQL richiede la conoscenza delle tassonomie prima di qualsiasi importazione. Se emergono nuove tassonomie, è necessario ri-ETL tutto. Questo non rende i database relazionali adatti come soluzione generale.
Se i file condividono la stessa tassonomia e la tassonomia è molto semplice (come in:non troppe dimensioni), è possibile elaborare una mappatura ad hoc per memorizzare tutti i fatti in un'unica tabella con molte righe nel ROLAP senso (dati a righe, aspetti a colonne). Alcuni fornitori sono specializzati nella memorizzazione di fatti XBRL non dimensionali, nel qual caso le offerte SQL tradizionali (o "post-SQL" che si adattano alle righe) funzionano bene.
Alcuni fornitori creano una tabella per ogni ipercubo XBRL nella tassonomia, con uno schema derivato dalla rete di definizione ma diverso per ogni ipercubo. Questo può portare a molte tabelle nel database e richiede molti join per le query che coinvolgono più ipercubi.
Alcuni altri fornitori fanno ipotesi sulla struttura XBRL sottostante o sul tipo di query che i loro utenti devono eseguire. Limitare l'ambito del problema consente di trovare architetture o schemi SQL specifici che possono anche svolgere il lavoro per queste esigenze specifiche.
Infine, per importare grandi quantità di archivi, è possibile creare mappature generiche su archivi dati NoSQL anziché su database relazionali. Un gran numero di fatti con un numero variabile di dimensioni si adattano a grandi raccolte di documenti semistrutturati e le reti si adattano bene a un formato gerarchico.
