ereditarietà della tabella di classe ... per 'digitare' o non per 'digitare'

Question

ereditarietà della tabella di classe ... per 'digitare' o non per 'digitare'

#1 da (3 voti)

3

Al momento ho un database che utilizza il modello di ereditarietà delle tabelle delle classi. Tre tabelle diverse ereditano da questa tabella. Le tabelle figlio hanno tutte un FK per la tabella padre e i campi sono correttamente indicizzati.

Attualmente stiamo riscontrando alcuni problemi a livello di applicazione perché è difficile capire a quale tabella figlio ci stiamo riferendo dal genitore. Oltre a questo, una query in cui organizziamo per tipo sembra costosa.

Uno sviluppatore sostiene che dovremmo unirci a tutte e 3 le tabelle per capire a quale bambino corrisponde il record padre, e fintanto che le tabelle hanno le query indice appropriate non dovrebbe essere costoso.

D'altra parte, potremmo evitare un sacco di confusione e problemi se aggiungessimo un campo discriminatore nella tabella genitore, in questo modo vorremmo sapere senza dover fare alcun join con il "tipo" di record con cui abbiamo a che fare. Anche il raggruppamento per tipo sarebbe molto più semplice.

Dovremmo aggiungere un tipo nella tabella genitore?
Quali sarebbero gli svantaggi?
È davvero inutile unirsi a più tavoli (purché sono correttamente indicizzati) rispetto ad avere un campo discriminatore?
Altri pensieri?

Attualmente stiamo utilizzando un'implementazione di record attivo per PHP e non supporta l'ereditarietà delle tabelle di classe.

php inheritance mysql

posta Onema 17.04.2013 - 01:55

fonte

1 risposta

Leggi altre domande sui tag php inheritance mysql

Come soddisfare la licenza EASTL Il registro attivo di Ruby on Rails è un esempio di programmazione orientata agli aspetti?

score 3 · Accepted Answer

Vedo questi vantaggi dell'utilizzo di type nella tabella di base:

Saprai esattamente quali altre tabelle leggere.
Saprai direttamente quale classe concreta istanziare quando idrati.
Sai che tipo di dati hai solo guardando la riga della tabella padre.

E questo svantaggio:

Se si recupera l'istanza tramite l'applicazione, sarà necessario emettere due query: una per recuperare i dati della tabella di base e un'altra per recuperare i dati dei figli, dato il% co_de trovato. (Questo può essere alleviato usando una stored procedure che incapsula quella logica.)

D'altra parte, non penso che un join di tre tabelle dovrebbe essere un problema, ma ricorda che devono essere type se non stai usando un discriminatore outer joins nella tabella genitore. Semplicemente non sai che tipo di tipo stai guardando. Ma, come al solito, profilo di conseguenza.