Quale approccio sarebbe meglio per mantenere queste chiavi e valori di configurazione sovrascrivibili? Un semplice archivio di valori-chiave o un database grafico?

Question

Quale approccio sarebbe meglio per mantenere queste chiavi e valori di configurazione sovrascrivibili? Un semplice archivio di valori-chiave o un database grafico?

#1 da (1 voti)

2

Sto creando un sistema in cui sono presenti chiavi e valori di configurazione. Quindi per esempio:

config.key = 10

È un esempio di una chiave di configurazione e un valore. Queste chiavi possono avere anche delle sostituzioni basate su "dimensioni". Ad esempio, se volessimo applicare config.key alle applicazioni con la dimensione foo , la chiave sostituita sarebbe essenzialmente:

config.key.foo = 20

In futuro potremmo avere più dimensioni in ordine arbitrario, quindi questa potrebbe essere una possibilità in futuro:

config.key.foo.bar = 30

Un esempio più concreto sarebbe se avessimo una chiave / commutatore chiamata display.pintrest.feed che ha un valore boolean . Quindi il valore predefinito sarebbe false , ma potresti avere delle sostituzioni in questo modo:

display.pintrest.feed = false
display.pintrest.feed.femaleUser = true

Qui femaleUser è una dimensione (quindi vogliamo impostare il valore di questa configurazione su true solo per utenti di sesso femminile).

Questo è essenzialmente ciò che sto cercando di fare. La mia domanda riguarda la persistenza. Quale sarebbe il modo migliore per mantenere questo tipo di dati? Si tratta di dati che verranno interrogati con una certa frequenza ma scritti meno spesso. La soluzione ingenua sarebbe usare MySQL o PostgreSQL e creare una tabella come questa:

+----------------------------------+-------+
|                Key               | Value |
+----------------------------------+-------+
| config.key                       | 10    |
| config.key.foo                   | 20    |
| display.pintrest.feed            | true  |
| display.pintrest.feed.femaleUser | false |
+----------------------------------+-------+

Ma perdiamo la sicurezza del tipo di Value e abbiamo anche un singolo punto di errore. Abbiamo anche molta ridondanza (la parte di base della chiave di configurazione viene ripetuta ogni volta). Quindi mi sono chiesto se fosse possibile rappresentarlo come un grafico in modo da poterlo scrivere su un database grafico. Stavo pensando di modellarlo in questo modo:

Questo è vitale o eccessivo?

Non mi dispiace usare un semplice archivio di valori-chiave, ma dovrebbe essere tollerante agli errori e dovrebbe essere in grado di essere raggruppato. Inoltre ci preoccupiamo solo della coerenza finale (ad esempio, non importa che ci sia bisogno di tempo per propagare le modifiche a tutti i nodi).

Quindi la mia domanda è che tipo di data store dovrebbe supportare questo tipo di dati? È sufficiente un semplice archivio di valori-chiave o devo andare per un database grafico? Il mio fondamento logico per quest'ultimo è semplicemente quello di mitigare la ridondanza dalle chiavi, ma non so se questo è un strong fondamento logico.

database configuration graph graph-databases persistence

posta Vivin Paliath 01.08.2014 - 19:30

fonte

1 risposta

Leggi altre domande sui tag database configuration graph graph-databases persistence

Coda di lavori in stati diversi e con diversi servizi in giro Strutturazione di un sistema di archiviazione per un gioco

score 1 · Answer 1

Potresti usare una struttura leggermente diversa nella tua tabella, se volessi continuare con una soluzione basata su tabella:

key_values
----------
  id
  parent_id
  key
  value
  type_constraint_id

type_contraints
---------------
  id
  name

e poi compilare in questo modo:

key_values
----------
id  | parent_id | key       | value    | type_constraint_id
----+-----------+-----------+----------+-------------------
1   |           | config    |          |
2   | 1         | key       | 10       |
3   | 2         | foo       | 20       |
4   |           | display   |          |
5   | 3         | pinterest |          |
6   | 5         | feed      | true     |
7   | 6         | femaulUsr | false    |


type_constraints
----------------
id  |   name
----+-----------
1   | numeric
2   | boolean
3   | text

Questo schema ti consente di archiviare la gerarchia in modo tale da poterla interrogare direttamente, poiché sembra che ti interessi lavorare in questo modo.

Ho anche aggiunto una tabella type_constraint e FK in modo che sia possibile associare le chiavi ai tipi denominati. Il database non è in grado di applicarle in modo efficace, quindi dovresti usarlo come suggerimento per l'applicazione per eseguire la convalida del tipo (o farlo nel database con i trigger). Non sono sicuro che mi preoccuperei se lo stessimo costruendo da solo, ma sembra che tu voglia avere una sorta di sicurezza del tipo, questo era il modo più semplice che potessi pensare per aggiungerlo a questo schema.

Suppongo che un database grafico funzioni se queste strutture chiave / valore diventano molto complesse, ma non sono abbastanza familiare con loro per sapere se offrono il tipo di sicurezza che si desidera e funzioneranno nel modo desiderato.