Come funziona l'aggregazione quando sono coinvolti i database?

Question

Come funziona l'aggregazione quando sono coinvolti i database?

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

2

Quindi sto leggendo un libro su Design Patterns (Design Patterns Explained 2nd Edition), e in tutto il libro si dice che "favorisce l'aggregazione sull'ereditarietà".

Sto provando a girare la testa cercando di progettare qualcosa, e mi sento così stupido.

Quindi concettualmente, ho Recruiters . Ho pensato che questi reclutatori possano essere una classe astratta, perché ho un paio di tipi diversi di reclutatori ... a tempo pieno e a tempo parziale. Il fatto è che voglio che ogni reclutatore abbia riferimenti ad altri reclutatori perché potrebbero lavorare insieme e condividere e combinare le informazioni.

Ciascun Reclutatore avrebbe uno o più% diRegions da supervisionare, magari condividendolo con altri Reclutatori. Tutta la regione è un aggregato concettuale di SubRegions . Le sottoregioni definiscono luoghi che ricadono lungo determinati confini geografici. Questi contengono alcune informazioni statistiche numeriche sulle assunzioni per quella Sottoregione nel suo insieme.

Le sottoregioni sono costituite da Recruitments , che contiene informazioni dettagliate su particolari eventi di reclutamento per una Sottoregione. Contengono anche altre informazioni statistiche che hanno senso essere in reclutamento (perché sono molto specifiche per il reclutamento), ma non sotto Sottoregioni. Ogni volta che vengono aggiornate alcune informazioni del reclutamento, è necessario creare un nuovo record di quella transazione in modo da poter conservare una cronologia di come i numeri si stanno adeguando.

Ora, voglio che tutti questi possano essere archiviati in un database. Sono molto ingenuo quando si tratta di progettare e strutturare i database, specialmente quando si tratta di gestire classi e interfacce astratte che sono nuove per me.

Tutto nel database sarà collegato in qualche modo, tra tabelle diverse. Supponiamo che i Recruiter diventino una tabella e che ci sia una tabella Region, una tabella SubRegion e una tabella Recruitment.

Dove è necessario inserire la logica e come inserirla, in modo tale da poter essere sicuro di poter salvare tutto nel database, accoppiato bene, ma accoppiato nel codice?

design database abstraction

posta Cowman 08.10.2013 - 02:30

fonte

2 risposte

0

Le tabelle descrivono principalmente le relazioni, non necessariamente gli oggetti. Il tuo progetto contiene le seguenti relazioni:

Recruiter n:m Region
Region    1:n SubRegion
SubRegion 1:n Recruitment

... e ognuno di questi potrebbe essere una tabella a parte. Le istanze di reclutatori e regioni ecc. Sono indicate qui da un ID. Dato un oggetto, può cercare gli attributi nel database tramite il suo ID:

I'm subregion 14. What are my recruitments?
SELECT Recruitment FROM SubRegion_Recruitment WHERE SubRegion = 14

Ovviamente, lo si astragga attraverso qualcosa come oggetti di accesso ai dati o simili.

risposta data 08.10.2013 - 02:57

fonte

Leggi altre domande sui tag design database abstraction

Automatizzare i test in un browser non supportato dal selenio Database di test delle unità: testare tutte le possibili permute di lettura e scrittura sulla tabella?

score 1 · Accepted Answer

Penso che potresti confondere gli oggetti in un linguaggio di programmazione con tuple in un database. Non hai ereditarietà di oggetti in un database, a meno che non si tratti di un database orientato agli oggetti. Sebbene sia possibile simulare l'ereditarietà in un database orientato alla tabella, di solito non viene pensato in questo modo. Quando lo è, designiamo una relazione 1: 1, dove Recruiter è la tabella principale e AdvancedRecruiter (o qualcosa di simile) è la tabella collegata con le informazioni aggiuntive che appartengono all'oggetto discendente.

La cosa che devi chiederti quando progetti qualcosa di simile in un database è la stessa cosa che ti chiederebbe quando stai progettando una gerarchia dell'ereditarietà in un linguaggio di programmazione. La domanda è, c'è qualche raccolta di dati o comportamenti associati a qualche forma di reclutatore "potenziato" che non appartiene all'oggetto principale del recruiter, ma è un sottoinsieme naturale dell'oggetto principale del reclutatore? Se hai quello (che sospetto tu non lo sia), allora hai un candidato per ereditarietà. Se non lo hai, basta creare una tabella Recruiter e inserire tutto ciò che riguarda un reclutatore (tranne gli elenchi di cose, che sono tabelle separate con una relazione 1: many con Recruiter).

Ciò che chiamate "favorisce l'aggregazione sull'eredità" Ho sempre sentito chiamare qualcos'altro: "favorisci la composizione sull'eredità". Significa che dovresti, quando possibile, comporre oggetti; cioè, combinarli insieme in modi utili facendoli parlare tra loro attraverso le loro rispettive interfacce, o avendo un oggetto in possesso di uno o più riferimenti a un altro oggetto; piuttosto che avere gli oggetti ereditati l'uno dall'altro. La composizione favorisce un codice più sciolto e più altamente coeso. Ma ancora una volta, niente di tutto questo ha molto a che fare con i database.