Relazioni di gruppo: dettagliate o dirette?

Question

Relazioni di gruppo: dettagliate o dirette?

#1 da (1 voti)
#2 da (0 voti)

0

Design attuale

Ho un modello Person :

PersonId    Name            
----------- ---------------- 
1           Jessica         
2           Jennifer

Allora ho un modello Share che ha il Person e un Item associati.

ShareId     ItemId            
----------- ----------------
1           1         
2           2

E infine ho un SharePeople che dice a tutte le persone che hanno accesso a quell'articolo.

ShareId     PersonId            
----------- ----------------
1           1         
1           2

Nuova funzione

Ora è necessario aggiungere una nuova funzione, che è Gruppi. Quindi ho pensato a due aproaches e mi piacerebbe sapere qual è il più corretto.

Ci sono due cose che vedo chiaramente:

aggiungi una nuova proprietà IsGroup al modello Person .

PersonId    Name             IsGroup
----------- ---------------- -----------
1           Jessica          False
2           Jennifer         False
3           Blondes          True

crea una tabella GroupPeople

GroupPersonId    ChildPersonId          
-------------    ---------------- 
3                1    
3                2

Le domande

OPZIONE 1 : dovrei creare l'associazione su SharePeople con le righe IsGroup direttamente:

ShareId     PersonId            
----------- ----------------
2           3

OPZIONE 2 : dovrei creare l'associazione sempre con le persone che fanno parte del gruppo e fare in modo che un'altra colonna identifichi da quale gruppo è stata creata l'associazione.

ShareId     PersonId            GroupPersonId
----------- ----------------    -------------
2           1                   3
2           2                   3

La seconda opzione è più semplice quando si prelevano i dati dalle tabelle, sarà veloce e creerà meno impatto, tuttavia crea molte righe sul database.

La prima opzione è più pulita, ma dovrò fare un sacco di istruzioni logiche all'interno del mio codice mentre la riga è un gruppo o una singola persona.

Ma la linea di fondo è che non so davvero cosa c'è di meglio per quanto riguarda le prestazioni, e non voglio nemmeno fare tonnellate di codice dispari.

Grazie mille,

database-design

posta Christopher Bailey 12.04.2015 - 11:51

fonte

2 risposte

Leggi altre domande sui tag database-design

Come pianificate i rilasci con le nuove funzionalità in un modello di diramazione di sviluppo / rilascio? Gestione più efficiente delle risorse (immagine, documenti) in un grande progetto web

score 1 · Answer 1

Per l'Opzione 1, sembra che manchino i dati su quali persone ci sono in ogni gruppo, e ora ogni query sulla tabella Persona deve conoscere queste "persone del gruppo" fasulle, anche quelle che non si preoccupano della condivisione o gruppi.

L'opzione 2, legando la mappatura del gruppo persona- e gt; alla mappatura di persona- e gt; persona (che in realtà non hanno nulla a che fare l'uno con l'altro), sta effettivamente facendo presupporre che ogni persona fa parte di al massimo un gruppo . Probabilmente non è un presupposto sicuro.

Da qualche parte, ci deve essere una tabella che mappa personeId in groupIds, così sai chi è in ogni gruppo. Poiché questa è probabilmente una relazione molti-a-molti (un gruppo può avere N persone e una persona può essere in N gruppi), questa dovrebbe essere una tabella Gruppi completamente separata, non parte delle tabelle Persona o Condividi .

Questo significa che le tue query di condivisione / raggruppamento avranno più join, ma i join non sono difficili e una query corretta che il raggruppamento di intese è molti-a-molti è molto meglio di un semplice ma query errata. Non preoccuparti delle prestazioni finché non hai un problema misurabile, e anche in questo caso dovresti concentrarti sulle funzionalità standard di ottimizzazione del database come gli indici e la replica (che hanno maggiori probabilità di migliorare le prestazioni rispetto alla macellazione della progettazione dello schema).

score 0 · Answer 2

Non aggiungere isgroup alla tabella delle persone. Crea una tabella di gruppo come propria entità.

Modello di sicurezza basato su ruoli: persona, ruolo, gruppo, roleonGroup, roleonUser, permesso, itemPermission, itemPermissiononRole

o

persona, ruolo, gruppo, roleonEntity, permesso, itemPermission, itemPermissiononRole

dove "entità" può essere una persona o un gruppo. Preferisco il primo anche se richiede più codice.

Sto suggerendo itemPersmission invece di Share perché puoi avere più di una autorizzazione su un articolo, ad es. crea elemento, leggi elemento, scrivi elemento, elimina elemento, che può quindi essere assegnato per ruolo.

Puoi adattare i nomi al tuo modello, ma l'idea è che Share è un permesso e non ha bisogno della sua stessa entità.

Se questo sembra eccessivo per le tue esigenze, considera ciò che accadrebbe se cambiassero le tue esigenze e, oltre a condividere, avessi modificato. Molto rapidamente lo schema e il codice sarebbero sfuggiti di mano.