Rappresenta la gerarchia delle classi nel database (ereditarietà JPA)

Question

Rappresenta la gerarchia delle classi nel database (ereditarietà JPA)

#1 da (0 voti)

0

Sto lavorando all'applicazione di gestione del personale per una clinica, scenario di base, ma l'apprendimento dell'ereditarietà dell'APP mi ha portato a riflettere su alcune parti e ho bisogno di aiuto per chiarire i miei pensieri e il mio design.

SCENARIO:

Ho alcune classi ovvie: impiegato, impiegato, personale medico, infermiere, dottore ... ecc ... la conformità a una gerarchia di classi in cui ognuno è un dipendente, un infermiere e un medico sono personale medico :

employee <__ clerk
          |__ medical staff<__ nurse
                            |_ doctor

e ho pensato di rappresentare questa gerarchia con le classi java usando la strategia per la tabella di ereditarietà JPA.

I professionisti

Ogni classe riutilizza dati e metodi dalle classi padre.
Il database garantisce l'integrità dei dati soprattutto per le relazioni con altre entità, ovvero una relazione paziente con un medico non con un impiegato .
Il design è logico e bello.
Questo design è a prova di futuro, in quanto è necessario aggiungere molte tabelle in futuro se sono disponibili più dati.

I contro

Penso di esagerare.
Troppe pagine da inserire e amp; & modifica dati.
Tabelle (nella vista) che contengono dati di più di un'entità sembra scadente e la gestione dei controlli di classe Cast e di tipo è complessa.

Quindi ho bisogno di qualche consiglio su tale design, qual è la strada da percorrere? e cosa mi manca?

inheritance database-design

posta alibttb 07.10.2018 - 11:04

fonte

1 risposta

Leggi altre domande sui tag inheritance database-design

Progetta una gerarchia ad albero delle classi di proprietà Installare un altro sistema operativo nel contenitore docker?

score 0 · Accepted Answer

Per mappare l'ereditarietà delle tabelle ci sono tre strategie principali

Ereditarietà delle tabelle di classe : questo è ciò che pianifichi. Hai una tabella per ogni classe, quindi: employee , clerk , medical staff , doctor e nurse . Certo, è bello e sei al sicuro per l'evoluzione futura. L'inconveniente principale è che dovrai fare molti join per assemblare le parti di un'infermiera, mentre potrebbero non esserci molti campi specifici per gli infermieri dopo tutto.
Ereditarietà della tabella concreta : hai tabelle solo per le classi concrete e ognuna di queste tabelle conterrà tutti i campi per quella classe. Il vantaggio è che non è necessario assemblare le entità: tutti gli attributi sono in una tabella per una determinata entità. Sfortunatamente, questo rende il polimorfismo molto più doloroso; Ad esempio, qui, per un determinato dipendente, è necessario cercare in tutte le potenziali tabelle in cui questo dipendente potrebbe essere definito.
Ereditarietà della tabella singola : inserisci medici, infermieri e impiegati nella stessa tabella employee , ma mantieni alcune colonne specifiche della classe che rimangono vuoti per le righe di altre classi. Questo è meno bello, ma è estremamente pratico se dal punto di vista dei dati tutte queste classi sono molto simili.

Non sono uno specialista del settore sanitario, ma intuitivamente, penserei che infermieri, medici e impiegati di certo differiscano significativamente dalle loro abilità e comportamenti ma certamente condividono la maggior parte dei loro dati. In questo caso, l'ereditarietà del tavolo singolo potrebbe essere una scelta molto più pratica.