Come impostare un database SQL per soddisfare i record utente, i record di gruppo e i record predefiniti?

4

Struttura

Ho un'applicazione che carica i dati da un database. Non sto parlando dei dati dei clienti qui, però, sto parlando della configurazione dell'applicazione. Il database verrà quindi fornito con alcune impostazioni predefinite, che voglio rimanere invariato in modo che i futuri aggiornamenti possano essere importati e sovrascrivere quella configurazione.

Vorrei che il client fosse in grado di sovrascrivere alcune parti di tale configurazione e / o aggiungervi e / o rimuoverlo (che probabilmente non verrà effettivamente rimosso, solo contrassegnato come cancellato / disabilitato). Ma mi piacerebbe che anche un reparto e un utente fossero in grado di farlo e mi piacerebbe anche che le modifiche più rilevanti fossero caricate dal database.

Requisiti essenziali

  1. Il database contiene l'installazione dell'applicazione standard che non può (o non verrà modificata).
  2. Il database memorizza le modifiche in base a società, reparto o utente che forniscono modifiche all'impostazione standard. Queste potrebbero essere aggiunte alla configurazione, o modifiche alla configurazione esistente o alla disabilitazione della configurazione standard.

Il mio miglior sforzo

Una tabella con una chiave primaria combinata da due colonne: [Id] e [Ambito]. [Scope] determina se si tratta o meno dell'impostazione predefinita, di un record aziendale, di un codice reparto o di un codice utente. L '[Id] può quindi essere lo stesso per ciascuno, consentendo a ciascun livello del client di avere la propria configurazione dello stesso record. Ad esempio:

Id | Scope | Name         | Other columns...
==============================
 1 |    -1 | MyApp        | ...             <- Default record
 1 |     0 | Company Name | ...             <- Company record
 1 |     1 | Department X | ...             <- Department record
 1 |   101 | User X       | ...             <- User record

Non mi piace molto questo approccio, devo creare una vista che raggruppa tutti gli stessi ID e quindi seleziona il record più pertinente in base al tipo (cioè se non vi è alcun record utente, quindi usa il record del dipartimento, se nessun reparto utilizza la società e se nessuna azienda utilizza l'impostazione predefinita).

Molte informazioni non cambiano davvero all'interno del record, forse una o due colonne (a volte anche di più) e sembra inutile memorizzare gli stessi dati più e più volte.

Richiesta

Sto davvero cercando idee da persone su come memorizzare e organizzare meglio questo tipo di installazione, per favore?

    
posta Anupheaus 29.11.2016 - 21:57
fonte

1 risposta

0

Penso che quello che vuoi sia una tabella di database polimorfo:

configurations

id | configurable_type | configurable_id | ...
==============================================
 1 | application       |            null | ...
 2 | company           |    [company_id] | ...
 3 | department        | [department_id] | ...
 4 | department        | [department_id] | ...
 5 | user              |       [user_id] | ...
 6 | user              |       [user_id] | ...
 7 | user              |       [user_id] | ...
 8 | user              |       [user_id] | ...

In Rails, vorrei fare 4 query per trovare le diverse configurazioni e convertirle in hash:

application_config = Configuration
  .where(configurable_type: 'application')
  .first&.to_h

company_config = Configuration
  .where(configurable_type: 'company', configurable_id: company_id)
  .first&.to_h

department_config = Configuration
  .where(configurable_type: 'department', configurable_id: department_id)
  .first&.to_h

user_config = Configuration
  .where(configurable_type: 'user', configurable_id: user_id)
  .first&.to_h

Una volta che hai hash, puoi unirli uno sopra l'altro per produrre la configurazione finale:

configuration = application_config
  .merge(company_config)
  .merge(department_config)
  .merge(user_config)

Una cosa che potrebbe aiutare con questo sarebbe usare un campo JSONB per memorizzare le configurazioni reali (invece di mettere i valori in colonne specifiche del database). I due vantaggi offerti sono che JSON converte in hash bene, e JSON è estensibile, nel caso in cui si presenti una nuova opzione di configurazione in seguito.

Pensiero finale: probabilmente non memorizzerei la configurazione predefinita dell'applicazione in una tabella di database. Probabilmente lo memorizzerei in YAML e lo leggerò una volta al momento del caricamento (che suppongo tu possa fare anche dal database).

    
risposta data 14.01.2019 - 07:17
fonte

Leggi altre domande sui tag