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