Я предполагаю, что вы используете SQL Server.
Прежде всего, как кто-то сказал в операторах, рекурсивные хранимые процессы, хотя и возможны, не являются хорошей идеей в SQL Server из-за размера стека. Итак, любая глубоко рекурсивная логика сломается.
Однако, если у вас есть 2-3 уровня вложенности в лучшем случае, вы можете попробовать использовать рекурсию или CTE , что также немного рекурсивно (SQL Server 2005 и выше). Как только вам удастся обернуть голову вокруг CTE, это очень полезная техника.
Я не измерял, но у меня никогда не было проблем с производительностью в тех немногих местах, где я использовал CTE.
С другой стороны, курсоры - это большие проблемы с производительностью, поэтому я ( и половина интернета ) рекомендовал бы не использовать их в коде, который часто вызывается. Но так как курсоры представляют собой более классическую структуру программирования, похожую на foreach в C #, некоторые люди считают, что проще смотреть, понимать и поддерживать код SQL, который использует курсоры для манипулирования данными, по сравнению с каким-то запутанным чудовищным множественным SQL так что это не самая плохая идея использовать их в коде, который будет вызываться время от времени.
Говоря о while, он также переносит мышление программирования с основанного на множестве на основанное на процедурах мышление, поэтому, хотя оно относительно быстрое и не потребляет много ресурсов, оно все равно может значительно увеличить количество данных. операторы манипуляции, выдаваемые вами самой базе данных.
Подводя итог, если бы мне нужно было создать сложный хранимый процесс, где производительность превыше всего, я бы попробовал:
- Использование подхода на основе множеств (внутренние выборки, объединения, объединения и т. Д.)
- Использование CTE (понятное и управляемое для опытного пользователя, немного затененное для начинающего)
- Использование операторов потока управления (если, в то время как ...)
- Использование курсоров (процедурный код, легко следовать)
в таком порядке.
Если код используется гораздо реже, я, вероятно, переместлю 3 и 4 до 1 и 2, но, опять же, только для сложных сценариев, которые используют много таблиц и множество отношений. Конечно, YMMV, так что я бы протестировал любую процедуру, которую я делаю в реальном сценарии, чтобы реально измерить производительность, потому что мы можем говорить, пока мы не поседели, что это быстро и медленно, но пока Вы получаете реальные измерения, и нет никакого способа определить, улучшают или ухудшают изменения.
И, не забывайте, код работает так же быстро, как ваши данные. Нельзя заменить хорошую индексацию.