Tendo a fare commenti simili a quelli di Pekka, ma penso che il motivo per cui non possiamo ridere di questo è la tua affermazione "Questa informazione può tuttavia variare notevolmente". Ciò significa che non è realistico pianificare di analizzare tutto e proiettarlo nel database.
Non posso rispondere a tutte le tue domande, ma posso rispondere ad alcune di esse.
In particolare, non posso parlarti delle prestazioni su MySQL. L'ho visto in SQL Server, l'ho testato e ho scoperto che SQL Server esegue in memoria estrazioni XML molto lentamente, a me sembrava come se stesse leggendo da disco, ma è un po' esagerato. Altri potrebbero contestarlo, ma è quello che ho trovato.
"Mysql può sostituire database orientati ai documenti come CouchDB/Sesame?" Questa domanda è un po' troppo ampia, ma nel tuo caso l'utilizzo di MySQL ti consente di mantenere la conformità ACID per questi blocchi XML, supponendo che tu stia utilizzando InnoDB, cosa che non si può dire automaticamente per alcuni di quei database orientati ai documenti.
"Come e perché sono migliori/peggiori di un'applicazione dinamica che memorizza vari dati come attributi?" Penso che sia davvero una questione di stile. Ti vengono forniti blocchi XML che sono (presumibilmente) documentati e MySQL può navigarli. Se li mantieni come tali, risparmi un passaggio. Cosa si guadagnerebbe convertendoli in qualcos'altro?
I documenti MySQL suggeriscono che il file XML andrà in un campo clob. Le prestazioni potrebbero risentirne su documenti più grandi. Forse allora identificherai i documenti secondari che desideri estrarre regolarmente e inserire in una tabella figlio.
Sulla stessa linea, se ci sono sotto-documenti particolari che vorresti conoscere, puoi creare una tabella figlio, "HasDocs", eseguire una piccola pre-elaborazione e popolarla con i nomi dei sotto-documenti con i loro conta. Ciò renderebbe più rapida l'analisi statistica e renderebbe anche più veloce la ricerca di documenti con determinati documenti secondari.
Vorrei poter dire di più, spero che questo aiuti.
