Devo usare XML per memorizzare i valori di configurazione in un database?

-2

Ci sono un paio di risposte su SE che confronta tabella a riga singola con tabella nome-valore usata per le impostazioni di configurazione, ma non ho visto nessuno discutere di usare XML (o JSON) come coppia nome-valore modello.

Opzione A

UserID     AppID     ParamID    Value
1          1         10         5.40
1          1         11         John Smith
2          1         10         4.40
2          1         11         Jane Smith

Opzione B

UserID     AppID     Settings
1          1         <params><param><ID>10</ID><value>5.40</value></param><param><ID>11</ID><value>John Smith</value></param></params>
2          1         <params><param><ID>10</ID><value>4.40</value></param><param><ID>11</ID><value>Jane Smith</value></param></params>

L'opzione A è una soluzione semplice per coppie di valori-chiave e l'opzione B utilizza solo una configurazione XML serializzata per utente / app.

C'è qualche valore nell'usare XML invece di una semplice coppia chiave-valore?

    
posta Igor F. 23.12.2015 - 18:02
fonte

1 risposta

2

Mi riferirò all'opzione A come all'approccio "strutturato", cioè a quello in cui la struttura dei dati è conosciuta e compresa dal database, e all'opzione B come all'approccio "blob", in cui i dati sono solo un blob opaco di cui il database non sa nulla.

Le principali cose da considerare sono:

  • La memorizzazione di questi dati in modo strutturato consente di eseguire direttamente le query. Ti aspetti di avere un utilizzo per query come SELECT UserId WHERE ParamID = 10 AND Value > 5 in qualsiasi momento nel futuro?

  • L'approccio "strutturato" costringe i tuoi dati a inserirsi in questa particolare tabella di database relazionale. Se questi dati erano in forma "blob", sarebbe interamente a te decidere quale forma assumono i dati. Nel caso dei BLOB XML, imponi una forma ad albero sui tuoi dati, che è significativamente meno restrittiva delle righe in una singola tabella relazionale.

  • Se si archiviano i dati in forma blob, la struttura del blob di dati non è dettata dallo schema del database. Questo dovrebbe significa che ha uno schema separato (nel tuo caso, un file .xsd da qualche parte). Ciò significa che puoi cambiare la struttura del blob senza migrare l'intero database in un nuovo schema, ma significa più schemi / versioni da tenere traccia di.

Quindi, quale si utilizza dipende da quanto si vorrà scrivere query che possono "vedere dentro" questi dati, quanto è probabile che sia necessaria la flessibilità della struttura a più forme e se si abbiano due schemi preoccuparsi è un vantaggio netto. Dove lavoro, alcuni dei nostri dati sono strutturati, e alcuni di essi sono "sbarrati". Dipende.

    
risposta data 25.12.2015 - 14:32
fonte

Leggi altre domande sui tag