По умолчанию аргументы полностью компилируются. То есть замещение аргументов по умолчанию вместо отсутствующих аргументов выполняется во время компиляции. По этой причине, очевидно, что выбор аргументов по умолчанию для функций-членов не может зависеть от типа dynamic (т.е. времени выполнения) объекта. Он всегда зависит от типа static (т.е. времени компиляции) объекта.
Вызов, который вы написали в своем примере кода, сразу интерпретируется компилятором как bp->print(10)
независимо от чего-либо еще.
Метод Prepare
на самом деле на DbCommand
, что все классы, которые являются производными от него, подберут.
То, что он делает, зависит от поставщика базы данных, для которого DbCommand
предназначен. Тем не менее, можно с уверенностью сказать (хотя это и не абсолютное правило), что в большинстве мест, если команда является хранимой процедурой, она не выдаст никаких операций (она задокументирована как таковая для переопределения для Prepare
в SqlCommand
), поскольку хранимые процедуры обычно оптимизируют свои планы запросов из-за предыдущих вызовов, явных вызовов для оптимизации или при создании (опять же, в зависимости от базовой базы данных).
Однако, если вы не используете не хранимую процедуру, а скорее параметризованный запрос, сгенерированный на лету, то этот вызов даст базовой базе данных возможность сгенерировать оптимизированную версию запроса. .
Обычно вы делаете это, когда знаете, что собираетесь выполнить команду несколько раз в течение короткого промежутка времени (в действительности это зависит от базы данных и продолжительности кэширования планов запросов).
Следует отметить, что SQL Server (по состоянию на 2005, IIRC) кэширует параметризованные планы запросов в зависимости от использования после первого выполнения (я думаю, что кэш - это кэш с ухудшенным временем, который сбрасывается или скорость его затухания снижается при последующих использует), поэтому, если вы собираетесь совершать несколько вызовов с одним и тем же параметризованным запросом, вы можете не получить большого выигрыша от вызова на Prepare
, кроме как перенести работу по подготовке запроса заранее (что также может быть полезным, в зависимости от какую работу вы должны выполнить).
Гораздо больше информации можно найти здесь .
Однако имейте в виду:
В SQL Server модель подготовки / выполнения не имеет существенного преимущества в производительности по сравнению с прямым выполнением, поскольку SQL Server повторно использует планы выполнения. SQL Server имеет эффективные алгоритмы для сопоставления текущих операторов SQL с планами выполнения, которые создаются для предыдущих выполнений того же оператора SQL. Если приложение выполняет инструкцию SQL с маркерами параметров несколько раз, SQL Server будет повторно использовать план выполнения из первого выполнения для второго и последующих выполнений (если только план не устаревает из кэша процедур). Модель подготовки / выполнения все еще имеет следующие преимущества:
Поиск плана выполнения с помощью идентифицирующего дескриптора более эффективен, чем алгоритмы, используемые для сопоставления оператора SQL с существующими планами выполнения.
Приложение может контролировать, когда создается план выполнения и когда он используется повторно.
Модель подготовки / выполнения переносима на другие базы данных, включая более ранние версии SQL Server.