Jag tenderar att göra kommentarer som liknar Pekkas, men jag tror att anledningen till att vi inte kan skratta bort det här är ditt påstående "Denna information kan dock variera enormt." Det betyder att det inte är realistiskt att planera att analysera allt och projicera det i databasen.
Jag kan inte svara på alla dina frågor, men jag kan svara på några av dem.
Framför allt kan jag inte berätta om prestanda på MySQL. Jag har sett det i SQL Server, testat det och upptäckt att SQL Server utför XML-extraktioner i minnet mycket långsamt, för mig verkade det som om det läste från disk, men det är lite av en överdrift. Andra kan bestrida detta, men det är vad jag hittade.
"Kan Mysql ersätta dokumentorienterade databaser som CouchDB/Sesame?" Den här frågan är lite övergripande men i ditt fall kan du använda MySQL för att behålla ACID-efterlevnad för dessa XML-bitar, förutsatt att du använder InnoDB, vilket inte kan sägas automatiskt för vissa av dessa dokumentorienterade databaser.
"Hur och varför är de bättre/sämre än en dynamisk applikation som lagrar olika data som attribut?" Jag tror att det här verkligen är en stilfråga. Du får XML-bitar som är (förmodligen) dokumenterade och MySQL kan navigera i dem. Om du bara behåller dem som sådana sparar du ett steg. Vad skulle vinnas på att konvertera dem till något annat?
MySQL-dokumenten föreslår att XML-filen kommer att hamna i ett clob-fält. Prestanda kan drabbas av större dokument. Då kanske du kommer att identifiera underdokument som du regelbundet vill bryta ut och lägga i en underordnad tabell.
På samma sätt, om det finns särskilda underdokument som du vet att du kommer att vilja veta om, kan du skapa en underordnad tabell, "HasDocs", göra en liten förbearbetning och fylla i den med namn på underdokument med deras räknas. Detta skulle ge snabbare statistisk analys och även göra det snabbare att hitta dokument som har vissa underdokument.
Önskar att jag kunde säga mer, hoppas detta hjälper.