[MySQL] Progettazione database - relazioni di generalizzazione

[superpelo]

Ciao a tutti,
mi trovo a dover progettare un database in cui esistono diverse entità che sono da considerarsi generalizzazioni di una entità padre.
In altre parole, trattando il sito di contenuti quali testi, video, foto, ecc. tutti con carattersitiche comuni, si ha una situazione di questo tipo:

Contenuto_generico(id, mittente, tags, visualizzazioni, voti, pubblicato, [...]);
Foto(id, titolo, filename, [...])
Video(id, titolo, descrizione, preview, filename, [...])
Testi(id, titolo, testo, [...])
E via dicendo, si tratta di una decina di contenuti differenti che sono specializzazioni del contenuto generico.

Ora mi chiedo: conviene mantenere questa struttura padre->figli oppure è più sensato (in termini di implementazione e mantenimento) realizzare solo tabelle "figlie" che inglobano tutti gli attributi ereditati dal padre?

Grazie!

[marco_c]

una struttura così è magari più complessa da realizzare all'inizio, ma è poi più facilmente mantenibile e scalabile.
soprattutto se realizzi il tutto con programmazione a oggetti, in cui avrai una classe ContenutoGenerico e poi fai delle classi derivate com ad es: Foto che è una classe derivata da ContenutoGenerico, quindi eredita campi privati e metodi.
In questo modo risparmi molto codice e al crescere del progetto hai delle basi solide per estenderlo con facilità.

[superpelo]

Anche io penso la medesima cosa. All'atto pratico però mi chiedo quale sia la migliore strategia per collegare un record della tabella padre con il corretto record della tabella figlio. Il viceversa è ovvio e il problema non si pone.

Mi spiego meglio: a partire da una riga di contenuto_generico, come determino se tale contenuto è una foto od un video? E' opportuno inserire in contenuto_generico un campo con il nome della tabella figlio corretta? Esistono altre strategie? E come si possono compiere operazioni di JOIN partendo da tali presupposti?

[marco_c]

se hai questa esigenza, nella tabella contenuto_generico metterai un campo TIPO che inizializzi con una costante che identifica che tipo di oggetto rappresenta.
ma secondo me però questo non è necessario.
infatti, mi immagino che quando vorrai per esempio elencare tutte le foto farai una cosa così
$lista_di_foto = new ListaDiFoto()
Questa chiamata farà una query sulla tabella foto, quindi già lei tirerà fuori solo le foto.
Nella tabella foto ci sarà poi ovviamente un campo contenuto_generico_id che conterrà l'id relativo della tabella contenuto_generico. Ma siccome tu parti dalle foto e vai all'indietro con un join su contenuto_generico (e non viceversa) non ti serve sapere di che tipo è quel record della tabella contenuto_generico, sai già che è una foto.

[superpelo]

Purtroppo invece ci sarà l'esigenza di partire dal contenuto generico per andare a determinare di quale specializzazione si tratta (per questioni di reportistica, statistica, gestione, newsletter, ecc.).

Pensavo anche io di mettere nel contenuto generico un campo che determina la tipologia di contenuto specifico di cui si tratta però così facendo temo non si riesca ad andare direttamente a fare un'operazione di join, bisogna fare due differenti query: la prima per estrarre i record interessanti dalla tabella "generica", la seconda per recuperare le informazioni specifiche dalla giusta tabella.
E' uno scenario plausibile oppure esiste una soluzione migliore?