AntonariyЭти слова что-то говорят о программных объектах и ничего о "нативном формате", вокруг которого они навернуты. Все равно не понятно, о чем речь.
Для тех, кто заперся в танке и не желает от туда выбираться. Речь о том, что из БД нужно выбирать данные без какой-либо трансформации. Трансформацию производить средствами application layer.

P.S. "Нативно выбрать" - это чистой воды аллегория. Другими словами, как вижу так и отдаю. Если требуются еще уточнения по этому поводу или захочешь опять понасиловать мой моск, убей себя об стену.

AntonariyДля начала, откуда ты знаешь, что никакой трансформации не происходит неявно при получении данных application layer'ом?
А мне это и не нужно знать, уже достаточно то, что он делает SQL FOR XML выборки. Более того, рекомендует это зло всем куда ни попадя.

AntonariyЕму же из бинарного потока нужно слепить объекты, для этого его нужно распарсить.
Не пиши чушь, какой еще "бинарный поток". Он делает выборку из обычных таблиц сразу в виде XML.

AntonariyА потом, for xml наверное не пяткой писали, и сделали узкоспециализированную процедуру, заточенную на максимальную производительность при формировании xml-текста из данных бд.
Лом тоже не зря придумали. Но использовать его в качестве отвертки - занятие неблагодарное.

AntonariyНикакой универсальный парсер application layer'а не сравнится по скорости выхлопа с узко заточенным.
Я бы не торопился с такими безапеляционными выводами - это раз. Выхлоп из базы должен быть в виде рекордсета без какого-либо форматирования, условной логики и прочего бреда. Логикой должен заниматься application layer и только он. Тогда отмасштабировать решения будет в разы проще, про переносимость БД - вообще как два пальца.

AntonariyЧто же получается, если нам нужно отдать xml клиенту? Как минимум две трансформации. Одна из бинарного стрима, отдаваемого сервером, в объекты типа DataSet/IEnumerable, вторая из объектов в стрим, содержащий xml-текст. +1, если не в стрим, а в XmlDocument.
Да, так и только так. Более того, одному клиенту нужна определенная xsd схема, другому - другая, третьему - третья. Писать этот ужос на SQL - проще убить себя об стену. Нормальные люди (подчеркиваю, нормальные люди) пишут .NET трансформер, богатый по функциональности и быстрый по исполнению.

AntonariyА если посмотреть на for xml, то получается, что транформацию в xml нам уже сделал сервер максимально эффективным способом, а если от xml больше ничего не надо, можно сделать ADODB.Stream -> Response.Stream без переливания из пустого в порожнее объекта в объект.
Написал выше. Более того, сейчас у нас сиквел, завтра оракл, последавтра попросят mysql. Засада? У меня нет, ибо вся логика в application layer.

AntonariyНо все это общие соображения для сферических задач.
Учи матчасть.

Antonariy,

60 миллисекунд на всё (выборка из БД, сериализация) - 1000 экземпляров [Sales].[Customer], результат 181 Кб (в аттаче), простая рабочая машина (не сервер).

Маленькая скорость?

Entity Framework

ShSergeМСУ...Учи матчасть.
У меня FOR XML на нескольких десятках миллионов данных работает меньше секунды.
Здесь смеяться или плакать?
В эти сказки даже дед мороз не поверит, получишь out of memory exception. Иди расскажи это бабушкам во дворе, и то засмеют.

ShSergeМСУ, Это твоё любимое ОРМ сделает. А у меня - всё типтоп.
Я ж говорю, иди деду морозу расскажи сказки, как ты сериализуешь в строку несколько десятков миллионов строк.

Тут чувак вешается от 220 тыщ, и все ему пальцем у виска крутят...

http://stackoverflow.com/questions/5899719/sql-query-for-xml-runs-fine-in-2000-slow-in-2008-r2 The table itself contains 220,500 rows but the query rows returned is showing 129,810 before query stops. Is this simply a matter of not having enough memory available to the system? This box has 48 GB (Win 2008 R2 EE x64), instance capped to 18GB because its shared dev environment.

а ты у нас такой весёлый, десятки миллионов строк в XML пихаешь, и всё это у тебя работает меньше секунды. Серж, ты не болен случаем?

handmadeFromRuShSergeА как это по-русски будет?
нечего было сказать?
п.с. вы имхо не вкурсе "как это работает" по ваших большинству постов
Я порой диву даюсь от постов Сержа...

ShSergeМСУ, Я очень осторожно подвожу тебя к мысли, что таки стоит чего-то делать на сервере.
Если это "что-то" реально оправдано, но я не против. Например, ORM-ы не умеют с деревьями рекурсионно через CTE работать. Да, идем в обход транслятора и пишем что-то такое . Или пишем хп, если очень припечет и оно того стоит. Но эти обходные пути - мизер, по сравнению с реальными потребностями.

ShSergeНесколько десятков миллионов у меня группируются до нескольких миллионов (суммируются).
1. Как-то ты аккуратно начал включать заднюю. У тебя может и 10 миллиардов сгруппироваться в одну строку и ты будешь всем писать, что "У меня FOR XML на нескольких десятках миллиардах данных работает меньше секунды"? Ну не бред ли?
2. Во вторых, даже если ты схлопнешь в несколько миллионов и накроешь их FOR XML, у тебя всё-равно не получится быстро это сделат
3. В третьих, сериализовать миллионы строк - попахивает кретинизмом. Не находишь?

ShSergeА там - дело техники. Несколько миллионов прекрасно себе сериализуются в ХМЛ. Но на SQL-сервере , а не на сишарпе, или ОРМе.
Да что ты говоришь? Расскажи, за какое у тебя время "несколько миллионов прекрасно себе сериализуются в ХМЛ"?

ShSergeЩас не могу послать тебе тестовый запрос, но как-нибудь сам попробуешь.
Давай!

ShSergeПардон, не десятки миллионов а сотни. :)
Так, начинали с десятков миллионов. Потом, оказывается, в сторонке отплясывала группировка и речь была о нескольких миллионах. Теперь уже "сотни". Только непонятно чего, миллионов или тысяч?

P.S. Серж, ты даже облажался на такой элементарной теме, как FOR XML... Даже студент знает, что это нереально тормозная хрень, которая еще более менее приемлема на небольшом кол-ве данных (сотни строк, ну тысячи максимум). И то, если речь идет о небольших по размеру row.

Алексей К Тут похожая тема. Сервера приложений можно без напряга горизонтально масштабировать. Поэтому всякие развороты данных/преобразование в XML/шифрование/сжатие и т. п. нужно по возможности выносить из БД. Масштабирование сервера БД (кластеризации, репликации и т. п.) - занятие не для слабонервных.
Вот, сразу чувствуется подход профессионала. Старик Алексей никогда не лажает! :) (ну или почти никогда )