Мнения об использовании XML в качестве параметра хранимого процесса и возвращаемого типа

Question

Это ново для меня. У меня есть новый начальник на работе, который настаивает на том, чтобы каждый запрос, который мы сейчас выполняем, был sproc с сериализованными параметрами XML и возвращаемыми типами.

Я еще не проводил никаких тестов, но это кажется мне излишним и, возможно, убийцей производительности во многих отношениях. Каков ваш опыт?

Answer 1

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

Кроме того, вы не сможете использовать ни инструменты ORM, ни простые средства отображения наборов результатов (iBATIS или BLToolkit).

Answer 2

Эй, давайте возьмем наш наименее масштабируемый компонент и заставим его интенсивно работать с процессором; -p

Хорошо, это был язык в щеке. Xml в качестве аргументов и возвращаемых значений используется в нескольких определенных случаях со структурированными данными, но в целом плоский поток TDS (то есть сетки) намного эффективнее. Для ввода хорошими вариантами могут быть либо CSV (через udf), либо табличные параметры (SQL 2008).

Sql / xml в 2005+ намного лучше, чем с openxml - и действительно, после того, как xml сохранен и проиндексирован на сервере (с использованием типа данных xml), он довольно эффективен - но как вход и выход может узкое место, если вы не осторожны.

Не устанавливайте его по умолчанию, но рассматривайте его как один из доступных вариантов.

Answer 3

Это потенциально позволяет вам определенный уровень обратной и прямой совместимости (так как процесс может начать понимать дополнительные параметры) - но я бы сказал, что применять его по всем направлениям нелепо практически для всех пути.

Я предлагаю вам попросить вашего босса назвать технические причины, по которым он считает это хорошей идеей.

Answer 4

Некоторое время назад я был в той же ситуации, и, помимо производительности, у нас были некоторые действительно неприятные ошибки с этим подходом. Добавлять / удалять / переименовывать теги в документе Xml действительно легко, когда вы делаете это, если ваш SProc не обновляется, вы найдете необычные данные в БД. Мой совет: избегайте такого подхода - просто не делайте этого ...

Кстати, ваш босс из АО?

Answer 5

Существует необходимость в передаче сообщений строки данных между Клиентом (Браузером) и Сервером, выполняемыми программами Веб-сайта. Однако эти строки сообщений должны иметь простые структурные правила, которые позволяют быстро анализировать информацию в именованных аргументах и ​​компонентах поля аргументов. XML был создан как интеллектуальное упражнение, чтобы как-то описать сложные объектные отношения и атрибуты страницы, полной HTML-объектов. XML - очень педантичное эзотерическое упражнение для теоретиков профессора, но как практический инструмент для общения на большинстве веб-сайтов, это шутка.

Answer 6

Я уже говорил это и скажу еще раз: Серебряной пули нет.

Использование XML в качестве входных и выходных данных для ваших хранимых процедур является решением «серебряной пули», и оно доказывает только одно: то, что одно решение, которое может быть хорошим выбором в одном случае, крайне неуместно во многих (вероятно, в подавляющем большинстве случаев). из) другие.

Рассмотрим, если хотите, хранимую процедуру, которая не принимает параметров и возвращает единственное скалярное значение. XML явно перебор в этом сценарии.

Рассмотрим также хранимую процедуру, в которой вы передаете диапазон дат (два отдельных значения даты) и возвращаете все строки из набора объединенных таблиц, попадающих в этот диапазон. Инкапсуляция дат в XML может быть не излишней, но инкапсуляция переменного количества данных, которые вы получите обратно, может быть. Вы можете вернуть ноль строк. Ты можешь вернуть тысячи из них.

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

Итак, должны ли вы оштрафовать всю кодовую базу, потому что небольшая их часть страдает от проблем с изменчивостью? Или вы должны разработать решение, которое заключает в себе эти изменчивые наборы данных за правильно спроектированным фасадом, который защищает остальную часть системы от этой нестабильности?

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

Answer 7

Интересно. Разбор строк в SQL - непростая задача. , Чего бы достичь в xml? (конечно, не слабая связь, потому что разделение базы данных и уровня приложения уже достигается сохранением процедур)

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

Answer 8

Это действительно простой (читай: грязный) способ использовать отдельные параметры, которые могут сделать код, ссылающийся на вызов хранимой процедуры, более аккуратным и простым.

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

Звучит так, будто кто-то только что прочитал, что вы можете сделать это и думаете: "XML - это хорошо, верно?" не слишком долго думая о том, следует ли сделать это.