Ereditarietà a tabella singola

StackOverflow https://stackoverflow.com/questions/200765

Domanda

Una risposta a una mia domanda sulla progettazione di DB mi ha suggerito qualcosa chiamato ereditarietà a tabella singola. Ho fatto un po 'di ricerche su questo, ma non riesco a trovare così tante informazioni chiare su di esso.

Fondamentalmente quello che mi sembra di capire è che hai una grande tabella con tutti i campi in esso e anche un campo di tipo - e quindi il tuo livello ORM usa il campo di tipo per darti diverse viste degli oggetti. È corretto?

Ancora più importante, l'ereditarietà a tabella singola è una tecnica di progettazione del database "approvata"? Con questo voglio dire che è "sensato" usarlo? È anche sicuro usarlo o causa problemi?

L'altro problema è quanto funziona bene nelle rotaie? Ho trovato alcuni riferimenti ad esso dai binari - ma causa problemi facendo le cose in modo non convenzionale?

Qualsiasi aiuto molto apprezzato.

È stato utile?

Soluzione

È una buona idea? Dipende. Rompe la normalizzazione in quanto una tabella non ha un unico scopo. Cosa succede quando estendi la classe base per l'ennesima volta? Dovrai aggiungere colonne alla tabella. La maggior parte dei DB moderni non ha problemi in quanto è possibile modificare la tabella, ma per quanto riguarda il refactoring e la rimozione di una classe. Ora hai colonne che non hanno uno scopo.

Una regola empirica: se la maggior parte del design è stata elaborata, è probabilmente sicuro da usare. Se il design cambia frequentemente, hai altri problemi e devi bloccare i tuoi casi d'uso / requisiti dell'utente. (sì, non proprio XP compatibile)

Non conosco gli effetti di Rails.

Altri suggerimenti

La STI è un modo di affrontare una discrepanza tra il pensiero orientato agli oggetti e quello basato su database. Consente una rappresentazione ragionevole delle informazioni all'interno del database e una rappresentazione diversa all'interno del modello a oggetti.

Ad esempio, ho un'applicazione in cui ciascuno dei miei prodotti contiene una o più commissioni, ognuna calcolata in modo leggermente diverso. Nel mio modello a oggetti voglio avere sottoclassi di una classe Commissione, ognuna delle quali sa come calcolarsi. In realtà non voglio avere una tabella per tipo di commissione: quindi creo Commissione come classe base e commissioni come tabella, che contiene l'unione di tutti i campi necessari in tutti i sottotipi, oltre a un "tipo" ; colonna il cui valore corrisponde al nome della sottoclasse pertinente. Successivamente ActiveRecord gestisce l'impianto idraulico.

In breve, Single Table Inheritance (STI) è un modello di progettazione che consente una mappatura delle relazioni di ereditarietà OOP con il database. Se si definiscono sottoclassi dagli oggetti del modello ActiveRecord, è necessario considerare STI.

La STI è (originariamente?) documentata nel libro "Patterns of Enterprise Application Architecture" di Martin Fowler, ed è anche descritta nel libro canonico di DHH "Agile Web Development with Rails" (sezione 18.4, credo.) Mi riferisco a questi libri perché forniscono una spiegazione molto migliore di quanto potessi sperare di fare in questo spazio.

Sono fortemente in disaccordo con il sentimento espresso su www.matthewpaulmoore.com (collegato da Robintw in questo thread), che la STI è intrinsecamente una cosa negativa. Questa sembra essere una visione un po 'ingenua che sconta l'uso dell'eredità OOP. Ho usato la STI per creare alcune soluzioni eleganti in Rails, ma suppongo che tu possa abusare di qualsiasi modello di progettazione.

Definitivo riferimento . Consente a una singola tabella di memorizzare più oggetti che hanno una classe base comune.

Ruby on Rails utilizza una libreria chiamata Record attivo . Questo è un framework Ruby comune che supporta STI.

Posso solo parlare dalla (nuova) prospettiva ADO Entity Framework, che include la funzionalità TPT (table-per-type).

Qui è un buona serie di post di blog che introducono i concetti chiave (utilizzando Entity Framework) e su di esso è presente un documento MSDN qui .

Sembra esserci anche qualche guida quando si utilizza nHibernate per TPT, si trova qui .

C'è questo link che spiega ereditarietà tabella per tipo in SQL Server . Questo sembra avere un riassunto e un'introduzione abbastanza buoni al concetto.

Non sono sicuro dell'impatto che avrebbe su Rails.

Generalmente lo trovo utile, ma Ho riscontrato alcuni bug

L'esempio in quel link può fornire un utile quadro di come potresti usarlo.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top