私はペッカと同じようなコメントをする傾向がありますが、これを笑わせられない理由は、「この情報は大きく異なる可能性がある」というあなたの発言にあると思います。つまり、すべてを解析してデータベースに投影することを計画するのは現実的ではありません。
すべての質問に答えることはできませんが、一部の質問には答えることができます。
特に、MySQLのパフォーマンスについてはお話しできません。 SQL Serverで確認し、テストしたところ、SQLServerがメモリ内XML抽出を実行することがわかりました。 非常にゆっくりと、ディスクから読み取っているように見えましたが、それは少し誇張です。他の人はこれに異議を唱えるかもしれませんが、それは私が見つけたものです。
「MysqlはCouchDB/Sesameのようなドキュメント指向データベースを置き換えることができますか？」この質問は少し広範ですが、MySQLを使用すると、これらのドキュメント指向データベースの一部では自動的に言えないInnoDBを使用していると仮定して、これらのXMLチャンクのACID準拠を維持できます。
「さまざまなデータを属性として保存する動的アプリケーションよりも、どのように、そしてなぜそれらが優れている/劣っているのですか？」これは本当にスタイルの問題だと思います。 （おそらく）文書化されたXMLチャンクが与えられ、MySQLはそれらをナビゲートできます。それらをそのままにしておくと、ステップを節約できます。それらを他のものに変換することで何が得られるでしょうか？
MySQLのドキュメントでは、XMLファイルをclobフィールドに入れることを提案しています。ドキュメントが大きくなると、パフォーマンスが低下する可能性があります。おそらく、定期的に分割して子テーブルに入れたいサブドキュメントを特定します。
これらの同じ行に沿って、知りたいことがわかっている特定のサブドキュメントがある場合は、子テーブル「HasDocs」を作成し、少し前処理を行って、サブドキュメントの名前を入力します。カウントします。これにより、統計分析が高速化され、特定のサブドキュメントを持つドキュメントの検索も高速化されます。
もっと言えばいいのですが、これがお役に立てば幸いです。