Так как это не правильный XML, давайте попробуем некоторые низкоуровневые строковые инструменты.
mysql> SELECT SUBSTRING_INDEX(
SUBSTRING_INDEX(
'UPDATE</transactionType><column><name>prio</name><newValue>51</newValue><oldValue>11</oldValue><newValue>bbb<oldValue>10863321</oldValue></column></row></table></businessObjectChanges>',
'</newValue>', 1),
'<newValue>', -1) AS x;
+----+
| x |
+----+
| 51 |
+----+
1 row in set (0.00 sec)
Объяснение:
</newValue>
. <newValue>
Попробуйте другие строки.
Это должно работать для любой версии MySQL, по крайней мере, в течение десятилетия.
<oldvalue>
должен работать так же, и может быть вторым «столбцом» в SELECT
.
Вы могли использовать, ОБЪЕДИНЯЮТ (или ISNULL) как так:
WHERE COALESCE(@var1, col1) = col1
AND COALESCE(@var2, col2) = col2
AND COALESCE(@var3, col3) = col3
Я обычно делаю это :P
WHERE (@var1 IS NULL OR col1 = @var1)
AND (@var2 IS NULL OR col2 = @var2)
...
Можно поместить OR's в оператор Where как так:
WHERE
(@var1 = '' OR col1 = @var1) AND
(@var2 = '' OR col1 = @var2) AND
(@var3 = '' OR col1 = @var3) ...
Можно передать дополнительные параметры хранимой процедуре, но оптимизатор создаст план на основе определенных вызовов, Вы делаете к этому proc. Существуют некоторые приемы в SQL Server 2005 и позже избежать этого (сниффинг параметра, 'без компиляции' подсказки, и т.д.)
Даже с этим, tho, я предпочитаю создавать представление с ядром запроса и затем использовать то представление в нескольких procs с определенными параметрами. Это позволяет SQL оптимизировать, как он хочет/должен, и я все еще добираюсь для консолидации специфических особенностей запроса.
Альтернатива к динамично созданному SQL в Хранимой процедуре, это производит самый лучший план относительно запроса, и план будет создаваться и использоваться так или иначе (в 2005 и выше).
Еще лучше должен сделать параметр дополнительным ПУСТЫМ УКАЗАТЕЛЕМ и затем протестировать в операторе Where точно так же, как случай пустой строки...