ciao webus, dal tuo intervento vedo che è meglio se chiarisco la questione, anche se Luca200 ha già esaurito il thread, e penso di adottare la mia soluzione originaria usando un full-text.

Riepilogando, è ovvio che quando si parla di relazionare delle tabelle, non si intende "far copulare delle tabelle fra di loro" (nascono le tabelline), ma "relazionare record di tabelle": se ci si riesce a capire ugualmente usando sottintesi ed espressioni tecniche ci si trova meglio, si scrivono meno righe e ci si capisce subito, no?

Ad ogni modo non sto facendo confusione, e faccio riferimento a un tradizionalissimo sistema OLTP - non mi serve per BI o analisi multidimensionali ma per un portale, come ho scritto sopra.
Nei db relazionali, e aderendo alle leggi di Codd, i dati sono normalizzati, e per farla breve (sottintendo una serie di passaggi logici tra cui l'elencazione delle leggi di Codd, ok?) ne deriva tabelle diverse contengono dati diversi.
Le relazioni fra record di tabelle diversi normalmente vengono scritte in tabelle di correlaz (es. TabA.RecID 11 è in relaz con TabB.RecID55 e TabG.RecID21 = ho 1 record nella tabella di correlazione A-B e 1 record nella tabella A-G).
Dovendo replicare questo schema con 30+ tabelle di anagrafiche che sono quasi tutte correlate fra loro (nel senso che record della tabella A possono avere correlazioni con record delle tabelle B, C, D, E, F, G, H, I - continuo? ), dovrei scrivere 30! tabelle di correlazione, oppure 30!/n! dove n è il numero di tabelle che _non_ sono "correlate fra di loro" (sottintendo una serie di passaggi di calcolo combinatorio). In breve, dovrei scrivere tante tabelle, con "tante" = numero che secondo il mio limitato concetto di quantità tende a più infinito.
Non aveva senso fare questo calcolo finchè realizzavo cms o db di dimensioni limitate e settoriali, come portali per il dipartimento regionale dei trasporti, o per Conservatori di provincia, o per istituti di ricerca nucleare europei o italiani.

1) non ho voglia di strutturare 30+ tabelle di anagrafica, anche se adoro la fase progettuale pratica - non solo per pigrizia o mancanza di tempo, ma anche per motivi che magari vediamo in seguito
2) voglio che l'utente possa dire "questo evento W è legato al docente X e ai corsi Y e Z", ma non ha senso mettersi a prevedere tutti i possibili legami fra tutte le tabelle e scrivere le corrispondenti tabelle di correlazione: dev'essere un sistema più dinamico
3) la "scheda descrittiva" di ciascun item è un stringone XML all'interno di un campo text o BLOB (x Luca: dipende da come vengono inseriti e da come li posso consultare - alcuni metodi di accesso r/w richiedono che il campo sia BLOB e non text, anche se l'XML in sè è text)
4) ad item diversi corrispondono nodi XML diversi, ma qualsiasi tipo di item è memorizzato dentro questo field: questa è una violazioncina alle leggi suddette, ma nonno Codd capirà.
IN qs modo qualsiasi cosa vada a cercare, mi basta fare una ricerca LIKE o fulltext in un solo campo. Non me ne frega nulla di questioni di velocità o non velocità: sul piatto della mia bilancia velocità, flessibilità e rapidità di implementazione, con questo approccio, mi si sono equilibrate in maniera più che dignitosa.
5) classificare gli item secondo categorie anche trasversali diventa più semplice: la categoria diventa essa stessa un item, e l'enunciato "A appartiene alla categoria C" diventa un altro record nella tabella di correlazione.

Concettualmente, hai tanti cosi tutti dentro la stessa scatola: scarpe, mutandine di seta bagnate, minimoog, baiocchi, matroidi e gatti persiani. Se devi cercare tutti i cosi "marroni", o "lisci", o "grassi" non devi andare in giro per 20 scatole. Se vuoi avere ordine e vedere solo i gatti persiani, fai un select sulla tabella di correlazione per tirar fuori tutti gli item che sono correlati all'id dell'item corrispondente alla categoria "gatti persiani" (che poi non mi piacciono nemmeno).

Il trip è iniziato...