Эффективные последствия комментариев в хранимых процедурах SQL
Недавно на моем дневном задании было дано указание, что любые комментарии относительно наших хранимых процедур НЕ ДОЛЖНЫ существовать внутри хранимой процедуры, и должны использоваться расширенные свойства.
В прошлом мы использовали что-то вроде этого.
/*
* NOTE: Auto-Generated Procedure DO NOT MODIFY
*/
CREATE PROCEDURE dbo.MyProc
AS
SELECT *
FROM MyTable
GO
Таким образом, в любое время кто-либо открыл процедуру в SSMS, они увидели заметку, другие комментарии также существовали в процедурах документирования нашего процесса. Теперь я не знал о проблемах с производительностью и памятью. Однако у нас есть люди, которые настаивают на этом.
Мне не удалось найти какую-либо документацию, подтверждающую или отрицающую наличие проблем с производительностью и/или памятью с такими комментариями.
Итак, мой вопрос: кто-нибудь знает какую-либо документацию, которая может либо доказать, либо опровергнуть это?
Ответы
Ответ 1
Это замедлит компиляцию хранимой процедуры всего лишь крошечным битом, и это не должно часто случаться.
В основном это звучит как пугало. Учитывая, насколько полезными могут быть комментарии (в умеренных количествах), я хотел бы потребовать доказательства того, что комментарии ухудшают производительность. Это звучит как смехотворная политика для меня.
(Требовательные доказательства в любое время, когда кто-либо делает заявления об эффективности, являются хорошим общим правилом, особенно если они предполагают, что вы жертвуете удобочитаемостью или каким-либо другим положительным атрибутом ради предполагаемого прироста производительности.)
Ответ 2
Текст (включая комментарии) сохраняется в sys.sql_modules в SQL 2005+. Таким образом, он добавляет размер системной таблицы.
При компиляции для составления плана комментарии игнорируются: они являются комментариями. Как и любой разумный язык...?
Однако в некоторых случаях отладочные комментарии, по-видимому, все еще можно разобрать и повлиять на вещи.
Это то, что я видел некоторое время назад, но отклонил его (и искал его для этого ответа).