views:

525

answers:

2

Recently at my day-job were were instructed that any comments regarding our stored procedures MUST NOT exist inside the stored procedure and rather Extended Properties must be used.

In the past we used something like this.

/*
 * NOTE: Auto-Generated Procedure DO NOT MODIFY
 */
CREATE PROCEDURE dbo.MyProc
AS
SELECT *
FROM MyTable
GO

This way anytime anyone opened the procedure in SSMS they would see the note, other comments also existed in procedures to document our process. Now I was not aware of any performance/memory issues with this. However we have individuals that insist it does.

I have not been able to find any documentation to prove or deny the existance of performance and/or memory issues with this type of comments.

So my question is, does anyone know of any documentation that can either prove or deny this?

+10  A: 

It will slow down the compilation of the stored procedure just a tiny bit, and that shouldn't happen often anyway.

Basically this sounds like scare-mongering. Given how useful comments can be (in moderation) I would demand evidence that comments hurt performance. It sounds like a ridiculous policy to me.

(Demanding evidence any time someone makes claims about performance is a good general rule - particularly if they're suggesting that you sacrifice readability or some other positive attribute for the sake of the supposed performance gain.)

Jon Skeet
I agree, sadly in my situation I am responsible for providing the documention that they are wrong......
Mitchel Sellers
+3  A: 

The text (including comments) is stored in sys.sql_modules in SQL 2005+. So it adds to the system table size.

On compilation to produce a plan, the comments are ignored: they are comments. Just like any reasonable language...?

However, in some circumstances debug comments can apparently still be parsed and affect things.

This is something I saw a while ago but dismissed it (and searched for it for this answer).

gbn