Сборки SQL против кода приложения для сложных запросов в больших столбцах XML

Question

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

Мне удалось получить список всех отдельных значений для элемента, но не намного дальше. В итоге я написал невероятно сложный код T-SQL, чтобы сделать что-то, что кажется довольно простым в C #: пройтись по всем строкам в этой таблице и применить это (XPath | XQuery | XSLT) к столбцу XML. Я могу отфильтровать реляционные столбцы, чтобы уменьшить объем данных, но для некоторых запросов это все еще много данных.

Мой план состоял в том, чтобы встроить сборку в SQL Server (я использую 2008 SP2) и сделать так, чтобы она создавала индексированное представление на лету для данного запроса (у меня была бы другая логика, чтобы очистить это представление). Это позволило бы мне снизить сетевой трафик и, возможно, также позволить использовать такие инструменты, как отчеты Excel и MSRS, в качестве дешевого пользовательского интерфейса, но я вижу, что многие люди говорят: «просто используйте логику приложения, а не сборки SQL» , (Полагаю, я мог бы здесь совсем не лаять))

Перенос большого куска данных в веб-службу и выполнение там обработки также принесут свои преимущества - я менее стеснен средой SQL Server (поскольку я не живу внутри нее), и процесс установки проще , Но это значит, что я передаю много данных по сети, сохраняю их в памяти во время обработки, а затем выбрасываю некоторые из них.

Буду признателен за любой совет.

Спасибо

Edit:

Спасибо, ребята, вы все очень помогли. Проблема заключалась в том, что мы генерировали строку в таблице для файла, и каждый файл мог иметь несколько результатов, и мы делали это каждый раз, когда запускали определенную работу по сборке. Я хотел сгладить это в виде таблицы.

Каждое выполнение этого задания сборки проверяло тысячи файлов на наличие нескольких атрибутов, и в некоторых случаях каждый из этих тестов генерировал тысячи результатов (тесты MSIVAL были худшим виновником).

Ответ (дух!) Состоит в том, чтобы сгладить его до того, как оно попадет в базу данных! Основываясь на ваших отзывах, я решил попытаться создать строку для каждого результата для каждого теста в каждом файле, и XML просто содержал детали этого результата - это значительно упростило запрос. Конечно, теперь у нас есть сотни тысяч строк при каждом запуске этого инструмента, но производительность намного выше. Теперь у меня есть представление, которое создает упрощенную версию одного из классов результатов, которые выдаются заданием сборки - это возвращает> 200 000 и занимает <5 секунд, по сравнению с примерно 3 минутами для эквивалентного (сложного) запроса до того, как я пошел более плоский маршрут и от 10 до 30 минут для обработки файла XML старой (не связанной с базой данных) версии. </p>

У меня теперь есть некоторые проблемы с количеством подключений, но у меня есть идея, как это исправить.

Еще раз спасибо! +1 все вокруг

Answer 1

Я предлагаю использовать стандартные инструменты xml в TSQL.(http://msdn.microsoft.com/en-us/library/ms189075.aspx). Если вы не хотите использовать это, я бы порекомендовал обработать xml на другом компьютере. SQLCLR идеально подходит для небольших функций, но с ограничениями на используемые методы он имеет тенденцию кстаньте упражнением в разочаровании, когда вы пытаетесь делать более сложные вещи.

Answer 2

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

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

В конце концов, единственный способ узнать это - попробовать оба пути и выяснить, что имеет для вас смысл. Разработка на вашем компьютере с веб-сервисами, несомненно, будет проще, поскольку LINQ to XML - более элегантный способ анализа XML, чем XQuery, встроенный в T-SQL. С учетом информации, предоставленной вами в вашем вопросе, я могу сказать, что в долгосрочной перспективе T-SQL будет работать лучше для вас, потому что вы выполняете синтаксический анализ XML для каждой строки или, по крайней мере, для большинства строк в базе данных для целей отчетности. Распространение такой информации по сети просто ужасно. Тем не менее, если производительность не так важна, можно сказать, что нужно выбрать более простой и более удобный способ выполнения всего анализа на сервере приложений.