Qual è lo schema corretto da utilizzare in questo caso?

Puoi mappare l'ereditarietà alle tabelle del database nei seguenti modi,

• Mappa l'intera gerarchia di classi in una singola tabella : tutti gli attributi delle classi sono memorizzati in una tabella. Questa è una buona strategia per gerarchie di classi semplici e / o superficiali in cui vi è poca o nessuna sovrapposizione tra i tipi all'interno della gerarchia .

• Mappa ogni classe concreta alla propria tabella : viene creata una tabella per ogni classe concreta, ogni tabella include sia gli attributi implementati dalla classe che i relativi attributi ereditati. Questa è una buona strategia quando si cambiano i tipi e / o si sovrappongono tra i tipi è raro .

• Associa ogni classe alla sua tabella : crea una tabella per classe, con una colonna per attributi di business e qualsiasi informazione di identificazione necessaria (oltre alle altre colonne necessarie per il controllo della concorrenza e il controllo delle versioni ). Questa è una buona strategia quando c'è una significativa sovrapposizione tra i tipi o quando il cambiamento dei tipi è comune. .

Come detto, nessuna di queste strategie di mappatura è l'ideale per tutte le situazioni. Gli esperti consigliano di iniziare con una tabella per gerarchia all'inizio, quindi se necessario lo schema di rifattore di conseguenza.

Do you know how to call this described pattern?

Catalogo dei modelli di Enterprise Application Architecture chiama questo Mapper di ereditarietà .

Mi sono imbattuto in qualcosa di simile, con una tabella di base di Persone, un'astrazione utile e poi altre tabelle a seconda che siano Contractor, Client, ecc.

Per il design del tavolo, se il "sottotitolo" (nel tuo caso, Libro, articolo) non può esistere senza essere Contenuto, allora andrei con il tuo disegno e userei Content_ID come chiave per Libro e articolo come bene.

Dato che utilizzo PHP, ho una classe che gestisce Content, quindi una classe che estende quella per gestire Libri / Articoli.

Se stai usando il database, ti consiglio una VISUALIZZAZIONE che SELEZIONA e UNISCA le tabelle del Content-Book, e un'altra con Content-Articles per facilità d'uso.

Se conosci in anticipo l'intera serie di possibili tipi di contenuti, puoi utilizzare tabella per gerarchia e incollare tutti i sottotipi di libri, articoli, ecc. del contenuto in un'unica tabella, Se, d'altra parte, potresti (o già saprai) di aver bisogno di nuove sottoclassi di contenuti in seguito, userei table-per-subclass (come stai pensando)

Quindi, la mia domanda è chiedere: il mio insieme di sottoclassi di contenuti è completo o dovrebbe essere facilmente estendibile in seguito?

Il tuo modello è solido perché hai una strong idea dei diversi tipi di contenuti che vuoi gestire (libri, articoli, ecc.). Avere una tabella per ogni tipo di contenuto definisce i diversi attributi. Probabilmente puoi prevedere oltre il 90% dei tipi di cui avrai bisogno per diversi anni.

Se li metti in una grande tabella, avrai diverse colonne che saranno null. Ci sono alcuni database che hanno migliorato la gestione dei dati sparsi e possono risparmiare spazio. Dal punto di vista della query di dati, puoi includere facilmente diversi tipi di contenuti.

Ho visto diversi sistemi (principalmente app aziendali) in cui offrono una maggiore flessibilità per i campi definiti dall'utente. A differenza della tua situazione, non possono prevedere tutte le entità. Un modo flessibile per farlo è con un modello di valore degli attributi di entità . L'unione di tabelle aggiuntive e l'eventuale trasposizione di dati di riga in colonne, le prestazioni sono sacrificate rispetto alla flessibilità dell'utente. Fondamentalmente, vuoi che la tua app sia programmabile / guidata dal codice o guidata dall'utente / dati?

Potresti considerare come gestirai la ricerca. Ci sono strumenti là fuori per rendere questo più facile. Ho intenzione di costruire il tuo, devi occuparti di più tavoli.

Forse dovrebbe essere considerata una soluzione NoSQL ?