Salvataggio di dati tabulari simili a fogli di calcolo in un database relazionale?

Spero che questa domanda non sia troppo ampia o troppo soggetta a risposte convinte, dato che potrei davvero usare alcuni suggerimenti.

Sto cercando di trovare un modo per mantenere tabulari, fogli di calcolo come ¹ , dati in un back-end. Dato che i dati potrebbero benissimo essere piuttosto confusi (non facilmente identificabili come identici, anche se l'utente potrebbe averlo inteso essere), ho dei dubbi sul persistere in un database SQL relazionale.

Gli utenti saranno in grado di creare più tabelle di questo tipo:

+====================================================+
| category                                           |
+==============================+==========+==========+
| item                         |  type A  |  type B  |
+==============================+==========+==========+
| name                         |    value |    value |
+------------------------------+----------+----------+
| name                         |    value |    value |
+------------------------------+----------+----------+

I dati saranno semplicemente usati a scopi di rappresentazione, per dare una panoramica degli articoli categorizzati e dei rispettivi valori di tipo. Non verrà implementata alcuna logica di business relazionale tra i dati delle celle.

Per tabella, gli utenti saranno in grado di definire una certa quantità personalizzata di type colonne. Inoltre, non ci saranno troppi vincoli sui dati delle celle consentiti, ad eccezione delle celle value , che saranno numeriche ² . Infine, gli utenti saranno anche in grado di migrare item righe e type colonne tra le tabelle.

Originariamente, la mia idea era di persistere in un database SQL relazionale, che, semplificato, si riduce a questo:

category
------
id            PK
name

item
------
id            PK
category_id   FK category(id)
name
sortOrder

type
------
id            PK
category_id   FK category(id)
name
sortOrder

item_type_value
------
id            PK
item_id       FK item(id)
type_id       FK type(id)
value

I motivi principali per cui ho iniziato a dubitare di persistere in un database relazionale è che anche se un utente può voler dire type A in una tabella per indicare lo stesso type-a in qualche altra tabella, I ' Non sarò mai sicuro. E poiché non voglio limitare troppo l'utente (né voglio complicarmi un'interfaccia troppo complicata, come lasciare che gli utenti definiscano prima un type , che possono quindi selezionare da un menu a discesa, ad esempio, o chiedere se intendevano "type-a" a significare lo stesso "type A" ), dubito che questo si presta particolarmente bene per una configurazione relazionale, a parte forse la definizione di relazioni su quali celle appartengono a quali tabelle , ecc.

Se si devono assumere i suddetti limiti clementi, ha senso cercare un meccanismo di memorizzazione persistente alternativo rispetto a un database SQL relazionale?

In tal caso, potresti suggerire un meccanismo di persistenza particolarmente adatto per questo tipo di dati? NoSQL o XML, forse?

^{1) Forse il foglio di calcolo è un po 'fuorviante; saranno semplicemente le tabelle in cui gli utenti saranno in grado di inserire valori scalari (stringhe e / o numeri) nelle celle. Niente di più; niente formule, calcoli, ecc. "Spreadsheet-like" si riferisce al fatto che gli utenti saranno in grado di modificare i dati della cella in linea. Ecco dove finisce sostanzialmente la somiglianza.}

^{2) Anche il vincolo numerico non è così importante. Viene menzionato principalmente per dare un po 'di contesto.}