У меня есть возможность хранить данные в памяти в виде XML-документа или набора данных ADO с несколькими таблицами. Веб-страница, использующая этот объект, будет выборочно получать элементы данных на основе ключей.
Имеет ли один из этих объектов явное преимущество в производительности по сравнению с другим?





DataSet уже представляет собой XML-документ, своего рода. Одним из дополнительных преимуществ, которые вы получаете с набором данных, является связь между таблицами, поэтому вы можете фактически запрашивать DataSet как базу данных в памяти.
XML действительно хорош, особенно в определенных ситуациях, но при поиске большого количества данных.
Если это элементы, основанные на ключах, не имеющие отношения к другим таблицам, используйте XML, но будьте осторожны с большими подмножествами данных.
Исходя из того, что сказал Саиф, ваша самая большая проблема с XML будет связана с ключами от одного документа к другому. Вы можете создать уникальные ключи для всех узлов в документе, но у вас могут возникнуть неправильные коллизии, если у вас есть другой документ с аналогичной структурой, поскольку документы различны. Другими словами, вам нужно будет гарантировать отсутствие перекрытия путем временного слияния документов или создания другой схемы, которая объединяет дополнительные идентификаторы с динамически сгенерированными ключами.
В зависимости от вашего уровня комфорта с XPath и XLST вы можете создать таблицы и отношения с ADO, так как это проще. Вы можете группировать ключи, и у Джени Теннисон, который публикует сообщения в StackOverflow, есть отличный серии по этим методам.
Если вы решили пойти по пути XML и используете .NET 3.5, подумайте о новых классах XDocument, XElement (и других) в пространстве имен System.Xml.Linq. Вы можете использовать Linq to XML для запроса ваших XML-документов, и это довольно хорошо.
Насколько я помню, DataSet - это не XML, пока он не сериализован.