ereditarietà delle tabelle di Doctrine 2 e Concrete

0

Uso Doctrine 2 e ho letto alcuni articoli sulla mappatura delle strategie di ereditarietà con ORM. Ho visto tre strategie principali: "ereditarietà delle tabelle delle classi", "ereditarietà delle tabelle concrete" e "ereditarietà delle tabelle singole".

Con Doctrine 2, ho gestito un'installazione di "Class Table Inheritance" (CTI) e "Single Table Ereditarietà" (STI).

In alcuni casi, penso che usare la "Concrete Table Inheritance" sia la soluzione più appropriata, ma non ho trovato alcuna documentazione che mostri questa strategia in Doctrine 2.

Perché non c'è "Concrete Table Ereditarietà" con Doctrine 2?

È per le prestazioni? Qual è la ragione?

    
posta csblo 07.07.2014 - 17:22
fonte

1 risposta

0

L'ereditarietà della tabella concreta è una forma di eredità problematica in quanto richiede all'ORM di aggiornare più tabelle se cambia un campo in un supertipo. Il vantaggio è che non richiede l'unione con tabelle di supertipi in molti casi, ma viene, come detto, con il rovescio della medaglia che denormalizza il tuo modello. Non molti ORM lo supportano (Hibernate / NHibernate lo fa, ma mette in guardia contro di esso).

È solo un'opzione di ottimizzazione, non c'è alcun 'bisogno' logico per esso come in 'si adatta meglio alla mia applicazione', in quanto l'unica differenza con altre forme di ereditarietà è che è memorizzata in modo diverso nel DB.

Se possibile, stai lontano dai mapping di ereditarietà in ORM btw. Usalo solo se esiste un'eredità di entità chiara nel tuo dominio. Non usarlo per mappare aspetti strutturali OO puri al DB, ad es. evitare cose come un supertipo che ha solo campi come "CreatedBy" e "UpdatedOn" ed è quindi ereditato da tutte le entità.

    
risposta data 13.08.2014 - 10:53
fonte

Leggi altre domande sui tag