XML dentro blob MySQL?

[lordzoster]

Salve
sto realizzando un portale che prevede la presenza di numerose tipologie di "items" (eventi, corsi,docenti, materie, esami, documenti, allievi, ecc., in tutto circa 30 o più), ciascuna caratterizzata da un gruppo specifico di dati (es. eventi: data inizio, data fine, titolo, descrizione).
Tutti questi items sono ovviamente correlati fra di loro in vario modo (corsi > materie > docenti, ma anche eventi > docenti e eventi > materie, docenti < esami > documenti, e così via)
Se usassi 1 tabella di anagrafica per ciascun tipo di item, dovrei avere n-fattoriale tabelle di correlazione, ovvero 30! = 2,6525285981219105863630848e+32 tabelle (se la calcolatrice di winzozz non sbaglia).
Inoltre, se cercassi 1 dato particolare (es tutti gli item che hanno data di pubblicazione 30 maggio 2008) dovrei fare una union di query su tutte le tabelle i cui item contengono il dato "data_pubblicazione".
Una soluzione potrebbe essere una forte standardizzazione dei nomi dei campi, in modo da poter parametrizzare le query.
Ma data l'enorme varietà di items pensavo di descrivere ciascun item tramite un XML e memorizzarlo in un blob di un'unica tabella MySQL di anagrafica, "items", contenente anche l'ID dell'item e p.es. lo stato attivo/non attivo.
La correlazione verrebbe gestita da un'altra tabella MySQL: ID item1 | ID item2

a questo punto, supponiamo che tutti gli item che posseggono tale proprietà contengano il nodo <data_pubblicazione value=aaaammgg /> (o <data_pubblicazione>aaaammgg</data_pubblicazione>, non so quale sia meglio). QUando devo p.es. cercare un item con data pubblicazione 30 maggio 2008, cosa dovrei fare?
una query full-text?
una query like?
esistono altri sistemi per effettuare subquery all'interno di xml?
l'xml dentro blob di mysql non è una buona soluzione?

una alternativa è un misto: avere 30 anagrafiche ma 1 unica tabella di correlazione, in cui indico oltre agli ID degli item correlati anche le relative tabelle (o le tipologie), in modo da capire a che coppia di tabelle appartiene ciascuna coppia di item correlati.

attendo vostri pareri!

[luca200]

La questione ha l'aria un po' complicata, ma mi sembra abbastanza improbabile che CIASCUNA di queste 30 o più presunte tabelle debba essere correlata con TUTTE le altre.
Da un punto di vista della teoria dei db relazionali, la soluzione corretta è sicuramente la prima (quella del fattoriale ).
Se davvero le correlazioni sono troppe, con la seconda ipotesi (xml, che fra l'altro andrebbe magari in campi text, non blob) ti puoi scordare di fare ricerche con delle query (a meno che non esistano strumenti di cui ignoro l'esistenza ).
Quindi come compromesso ti suggerirei l'ultima, ma ripeto, prima farei un'analisi ben dettagliata su quante siano effettivamente le correlazioni

[lordzoster]

ciao Luca grazie per la risposta.
So che può sembrare strano ma se non è un 30 fattoriale poco ci manca: se vogliamo essere matematicamente esatti è un 30!/8!, cioè 8 categorie non saranno (direttamente) correlate fra loro. In tal caso il numero di combinazioni possibili scende drasticamente a 6578691959627754430464000000
Si tratta del portale di un ente di alta formazione, che nella prima versione avevo realizzato in modo più "consueto", ma dopo una attenta analisi delle necessità e delle modalità di utilizzo mi sono reso conto che la strada più pratica (non necessariamente più semplice) è questa.
In realtà volevo dare all'operatore la possibilità di associare qualsiasi item a qualsiasi altro; l'alternativa sarebbe costruire un motore di correlazione in grado di associare fra loro i vari item in base alle analogie delle coppie proprietà/valore, ma innanzitutto andrei oltre budget e cqm non mi pare giustificato un "valore aggiunto" così alto per un "semplice" portale.

Oppure prendo in mano Typo3...

[webus]

Originariamente inviato da lordzoster
sto realizzando un portale che prevede la presenza di numerose tipologie di "items" (eventi, corsi,docenti, materie, esami, documenti, allievi, ecc., in tutto circa 30 o più), ciascuna caratterizzata da un gruppo specifico di dati (es. eventi: data inizio, data fine, titolo, descrizione).
Tutti questi items sono ovviamente correlati fra di loro in vario modo (corsi > materie > docenti, ma anche eventi > docenti e eventi > materie, docenti < esami > documenti, e così via)
Se usassi 1 tabella di anagrafica per ciascun tipo di item, dovrei avere n-fattoriale tabelle di correlazione, ovvero 30! = 2,6525285981219105863630848e+32 tabelle (se la calcolatrice di winzozz non sbaglia).
Inoltre, se cercassi 1 dato particolare (es tutti gli item che hanno data di pubblicazione 30 maggio 2008) dovrei fare una union di query su tutte le tabelle i cui item contengono il dato "data_pubblicazione".
Una soluzione potrebbe essere una forte standardizzazione dei nomi dei campi, in modo da poter parametrizzare le query.

Mi pare che stai facendo un po' di confusione. Non si tratta di relazionare tabelle, ma righe, valori. Per quanto la differenza possa apparire sottile non lo è, ed e pure una incomprensione piuttosto diffusa.
Se la vedi in ottica di relazioni righe-valori non ti apparirà così inverosimile, tanto più che ha poco senso contare quante possono essere tutte le combinazioni possibili.

una alternativa è un misto: avere 30 anagrafiche ma 1 unica tabella di correlazione, in cui indico oltre agli ID degli item correlati anche le relative tabelle (o le tipologie), in modo da capire a che coppia di tabelle appartiene ciascuna coppia di item correlati.

Se ho capito bene ti riferisci, invece che a al modello relazionale a quello dimensionale, molto usato ad esempio in ambiente OLAP e per la Business Intelligence, anche se dal poco che ho capito dubito che sia la strada ottimale per te.

Ti suggerirei di spiegare innanzitutto meglio cosa devi fare.

[lordzoster]

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...

[webus]

Originariamente inviato da lordzoster
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.
...

ah, ok

[lordzoster]

non è mia consuetudine riaprire vecchi 3ad, ma volevo semplicemente fare una chiosa: il sistema che avevo in mente quando ho aperto il topic, e che descrivevo nel primo post, è proprio quello che Microsoft ha implementato in Azure, con la sua architettura di Authority, Container ed Entity.
Insomma, qualcosa di buono nella mia idea c'era...