Theoretisch wäre das natürliche Paradigma zum Speichern von XBRL in einer Datenbank OLAP, da es bei XBRL um Datenwürfel geht. OLAP auf einer relationalen Datenbank würde ROLAP heißen.
Dies ist kein triviales Problem, da Fakten aus einer großen Anzahl von Taxonomien einen sehr großen und spärlichen Würfel bilden können (für SEC-Einreichungen sind es mehr als 10.000 Dimensionen) und auch, weil die Erstellung eines SQL-Schemas die Kenntnis der Taxonomien vor jedem Import erfordert. Wenn neue Taxonomien auftauchen, muss alles neu ETL gemacht werden. Damit eignen sich relationale Datenbanken nicht als allgemeine Lösung.
Wenn die Einreichungen dieselbe Taxonomie teilen und die Taxonomie jedoch sehr einfach ist (wie in:nicht zu viele Dimensionen), ist es möglich, eine Ad-hoc-Zuordnung zu erstellen, um alle Fakten in einer einzigen Tabelle mit vielen Zeilen im ROLAP zu speichern Sinn (Fakten zu Zeilen, Aspekte zu Spalten). Einige Anbieter sind darauf spezialisiert, dimensionslose XBRL-Fakten zu speichern, in diesem Fall funktionieren herkömmliche SQL-Angebote (oder "Post-SQL", die mit Zeilen skalieren) gut.
Einige Anbieter erstellen eine Tabelle für jeden XBRL-Hypercube in der Taxonomie mit einem Schema, das vom Definitionsnetzwerk abgeleitet ist, aber für jeden Hypercube unterschiedlich ist. Dies kann zu vielen Tabellen in der Datenbank führen und erfordert viele Verknüpfungen für Abfragen mit mehreren Hyperwürfeln.
Einige andere Anbieter machen Annahmen über die zugrunde liegende XBRL-Struktur oder über die Art von Abfragen, die ihre Benutzer ausführen müssen. Das Einschränken des Umfangs des Problems ermöglicht es, spezifische Architekturen oder SQL-Schemata zu finden, die auch für diese spezifischen Anforderungen geeignet sind.
Um große Mengen an Ablagen zu importieren, ist es schließlich möglich, generische Zuordnungen auf NoSQL-Datenspeichern anstatt auf relationalen Datenbanken zu erstellen. Eine große Anzahl von Fakten mit einer unterschiedlichen Anzahl von Dimensionen passt in große Sammlungen halbstrukturierter Dokumente, und Netzwerke passen gut in ein hierarchisches Format.
