Approccio per confrontare le versioni della gerarchia

Question

Approccio per confrontare le versioni della gerarchia

#1 da (2 voti)

1

Sto cercando un approccio agnostico linguistico per quanto segue. Stiamo prototipando questo in DB relazionali e grafici, quindi, di nuovo, sono aperto ad ascoltare tutte le opinioni rispetto a quelle.

Ecco lo scenario:
  - Vista utente porzione di organigramma
  - L'utente modifica l'organigramma in modo che alcune persone segnalino al nuovo manager
  - Gli utenti vedono le vecchie e le nuove gerarchie fianco a fianco   - La nuova gerarchia viene mantenuta in modo che possa essere visualizzata da altri utenti

Quello che sto pensando attualmente è che cercherò in qualche modo di utilizzare Rails con la graffetta gemma, ma il primo problema a cui sto lavorando è garantire che i Dipendenti nidificati siano della stessa versione del genitore al in cima alla classifica. Ancora una volta, qualsiasi consiglio specifico qui sarebbe apprezzato.

Invia altre domande che hai.

architecture hierarchy development-approach

posta Joe Essey 27.04.2016 - 19:13

fonte

1 risposta

Leggi altre domande sui tag architecture hierarchy development-approach

Come rispettare il Disability Discrimination Act del 1995 durante lo sviluppo di un'app per iOS [chiuso] Restituisce le funzioni all'interno degli oggetti Javascript

score 2 · Answer 1

Penso che questo dipenda dal fatto che (A) la tua struttura sia abbastanza piccola da adattarsi facilmente alla memoria, e (B) se devi supportare molte parti diverse modificate contemporaneamente da persone diverse.

Con questo in mente, penso che la soluzione più semplice sia trattare la relazione-web come un'unica grande unità (una "radice aggregata"). È responsabile della registrazione solo delle relazioni , mentre i singoli Person / Employee annodano che punta a vivere la propria vita e sono responsabili della registrazione di nomi, titoli, ecc.

La tua "copia ufficiale" di un grafico ha un numero di versione per concorrenza ottimistica , un singolo numero (o timestamp .)
Quando l'utente desidera iniziare a apportare modifiche, viene creata un'istantanea e inserita in un altro oggetto che appartiene solo a quell'utente, ad es. un "Draft di riorganizzazione" o qualcosa del genere.
L'utente modifica e gioca con la bozza tramite un'interfaccia utente.
Quando l'utente tenta di salvare la bozza, controlla che il grafico del numero di versione non sia stato modificato in modo imprevisto. Se sono incoerenti, informa l'utente: "Oops, qualcun altro ha apportato un'altra modifica. Ricominciare."
Se le versioni sono OK, prendi la struttura dalla bozza e applicala alla copia ufficiale in una grande transazione, incrementando anche il numero di versione.

Altri pensieri:

La "bozza" dell'utente non deve essere più di una singola riga in una tabella, puoi mettere tutti i dati di relazione in un campo XML o JSON, poiché a quel punto è solo qualcosa con cui stanno giocando , nessun altro ha bisogno di interrogare su di esso.
Puoi scegliere di rappresentare la bozza dell'utente come un'istantanea fissa del grafico più una serie di modifiche, che ti consentirebbe di applicare facilmente le modifiche degli utenti alla copia ufficiale. Bonus: funzionalità "annulla" nell'interfaccia utente.
Se è necessario combinare la modifica del grafico e la modifica dei dettagli utente, quindi memorizzare un secondo livello di informazioni nella bozza per quello, e rendere i controlli di risparmio / transazione un po 'più complessi per coprire entrambi i tipi di modifiche.
Anche se puoi iniziare con un solo un grafico per un organigramma, questo schema ti consente anche di memorizzare altri tipi di web, come "chi riceve i loro avvisi quando sono in vacanza".