Pattern per un gruppo di entità con un membro primario richiesto

Question

Pattern per un gruppo di entità con un membro primario richiesto

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

6

Data un'entità padre con una raccolta di entità figlio dove deve esistere esattamente un figlio primario del gruppo?

Per rendere la domanda più concreta, ho visto un certo numero di modi in cui questo schema potrebbe emergere: un gruppo di persone in cui una persona è il leader oi dettagli di contatto di una persona in cui uno è primario. Ecco due diversi approcci che ho visto.

1. Contrassegna il membro come principale In questo approccio, un membro viene aggiunto al membro per designarlo come principale. Il vantaggio è che è semplice da implementare ed evita ulteriori relazioni. Lo svantaggio è che è più difficile applicare nel modello dati che un solo membro è primario e da una prospettiva di un oggetto, potenzialmente pone la responsabilità sul figlio che dovrebbe essere sul genitore.

2. Associazione aggiuntiva In questo approccio il genitore tiene traccia del membro principale del gruppo e memorizza l'id del bambino. Questo è in aggiunta ai bambini che memorizzano l'id del genitore come membro del gruppo. Ciò rende esplicito nel modello di dati che esiste un solo membro primario e che un indice può essere aggiunto per applicarlo. Lo svantaggio è che richiede due relazioni e c'è una possibilità che possano non essere d'accordo (il genitore indica un bambino che non appartiene al genitore).

Mi sembra che questo è un modello comune e deve essere documentato come modello di progettazione o modello di modello in un libro di architettura da qualche parte. Un modello simile potrebbe essere il punto in cui la raccolta è una cronologia e ce n'è una corrente, ma è un po 'più facile in quanto ogni membro avrebbe un intervallo di date che può essere indicizzato. Ci sono approcci migliori? O qualcuno può indicare dove questo modello potrebbe essere documentato in modo più formale?

architecture design-patterns database-design

posta g . 09.03.2012 - 16:10

fonte

3 risposte

Leggi altre domande sui tag architecture design-patterns database-design

Istanzia la classe corretta in base a qualche input Questa implementazione dello schema di stato ha senso?

score 6 · Answer 1

Tieni traccia dell'oggetto principale sull'oggetto padre

Il mio motivo è che l'oggetto principale ha due attributi: un elenco di figli e un figlio primario. Poiché entrambi sono attributi dell'oggetto padre, l'oggetto genitore dovrebbe contenere queste proprietà.

L'unica volta che metterei una proprietà IsPrimary su un oggetto figlio è se l'oggetto figlio avesse effettivamente bisogno di sapere se si trattava di un oggetto primario o meno, e anche allora gli oggetti figli non avrebbero dovuto essere a conoscenza dell'altro bambino oggetti per mantenere i suoi valori, quindi un oggetto genitore dovrebbe ancora essere responsabile per l'impostazione della proprietà IsPrimary .

Se sei preoccupato per gli oggetti figlio che fanno riferimento all'oggetto padre errato, l'oggetto padre imposta la proprietà Parent su tutti i bambini quando vengono aggiunti alla raccolta figlio dell'oggetto padre.

Per quanto riguarda un nome per questo, non lo so. Sembra un ComboBox o ListBox - qualcosa che trattiene gli oggetti e consente di selezionarne uno.

score 0 · Answer 2

Vorrei andare con l'opzione (1) perché oltre alle caratteristiche che hai identificato correttamente, richiede una piccola elaborazione specialmente quando il numero di bambini è piccolo. È sufficiente accedere alla tabella secondaria in caso di inserimento, lettura o aggiornamento.

Il problema con (2) è che ogni volta che aggiorni il bambino o inserisci un nuovo figlio primario, il genitore deve essere aggiornato. Anche se questo può essere fatto in molti modi, sembra che non abbia un valore pratico particolare e inoltre, la colonna non appartiene logicamente al genitore.

Altri problemi con approccio (2):

Approach (2) rappresenta una relazione 1-1 sul modello di dati (che di solito si consiglia di evitare).
Se elimini la riga designata come figlio primario dalla tabella figli, cosa farai per la riga padre? Ciò richiede 2 aggiornamenti.

Questo modello è una sorta di caso speciale dal m-m al modello, ma sarebbe troppo complesso implementare un modello m-m per questo caso. Il caso speciale è che la tabella di intersezione è un singleton.

score 0 · Answer 3

Lancerò una terza opzione là fuori. L'idea di "primaria" non è tanto una bandiera quanto una priorità di visualizzazione:

+-----------------------+            
| Entity Item           |            +----------------+
+-----------------------+            | Entity         |
| Entity Item Id (PK)   |            +----------------+
| Parent Entity Id (FK) | >----+---> | Entity Id (PK) |
| Display Order         |      |     +----------------+
| Child Entity Id (FK)  | >----+
+-----------------------+

Una priorità di visualizzazione di 1 potrebbe essere considerata "primaria" e tutte le altre "secondarie". Offre i seguenti vantaggi:

Se i figli sono opzionali, allora non hai valori di colonna NULL che occupano spazio nel tuo database. Semplicemente non hai record nella tabella "Entity Child". Nessun valore NULL da gestire.
Hai anche un ordine specifico per le cose
Aggiungendo un vincolo univoco sulle colonne Parent Entity Id , Child Entity Id e Display Order della tabella "Entity Child" si assicura anche che ciascuna entità abbia esattamente uno di ciascun ordine di visualizzazione.
Se hai bisogno di ulteriori metadati sulla relazione figlio, puoi aggiungere una colonna "Tipo figlio" in cui puoi definire, per esempio, le persone come "Leader del gruppo" rispetto a "Membro del gruppo".
L'aggiunta di una data di inizio e di fine a ciascun record "Entity Child" consente di tenere traccia delle informazioni cronologiche relative alle relazioni padre-figlio, se necessario. Potresti anche modellare relazioni temporanee, come un "ospite" in un gruppo in questo modo.