SQLServerCentral / Discuss Content Posted by Narayana Raghavendra / Article Discussions / Article Discussions by Author / Code Stored in Files Instead of Stored Procedures / Latest Posts

RE: Code Stored in Files Instead of Stored Procedures

galaxis — Mon, 25 Oct 2004 06:18:00 GMT

I've actually been implementing this technique for quite a while in certain situations where the flexibility is necessary to create dynamic SQL. You also have the ability to create temporary stored procedures from the dynamic code. Another benefit of this approach is that the code is database independent (a big drawback of SPs is that they're tied to a particular database) and I can use the code in a multitude of scenarios/databases and keep only 1 copy (1 copy? Oxymoron? Oh well). There are so many factors that are necessary to keep the supposed speed advantage of SPs; indexes in optimal health, statistics constantly updated (especially if lots of updating), and keeping SQL Server from dynamically recompiling them anyway! We have seen noperformance advantages for SPs in most of our tests/usage scenarios.

RE: Code Stored in Files Instead of Stored Procedures

5409045121009-7368 — Mon, 27 Oct 2003 15:55:00 GMT

quote:
With that said, the idea of the code existing in a file and potentially outside of the control of the DBAs makes the job of maintaining security on the SQL Server that much more difficult. What essentially is being done here is the SQL Server DBAs are being tasked with all the responsibility but none of the authority... they don't control who has access to the file.

RE: Code Stored in Files Instead of Stored Procedures

K. Brian Kelley — Mon, 27 Oct 2003 15:27:00 GMT

Agreed. Security people are paid to say no first. It doesn't make us very popular. With that said, business must make the decision between security and functionality based on risk. For some environments these represent a suitable low-risk solution that off-loads work from the DBAs.K. Brian Kelleyhttp://www.truthsolutions.com/Author: Start to Finish Guide to SQL Server Performance Monitoring http://www.netimpress.com/Edited by - bkelley on 10/27/2003 3:27:43 PM

RE: Code Stored in Files Instead of Stored Procedures

Andy Warren — Mon, 27 Oct 2003 04:14:00 GMT

I thought this one would be a little controversial! I think the security risks should be very heavily considered. That said, it did put forth an interesting idea and we always have room for those.Andyhttp://www.sqlservercentral.com/columnists/awarren/

RE: Code Stored in Files Instead of Stored Procedures

K. Brian Kelley — Fri, 24 Oct 2003 15:03:00 GMT

Weighing in from a security perspective, a lot of what is being said here is disconcerting. I'll offer a few brief comments:All of these cases make use of BULK INSERT. This would require users to be placed in the bulkadmin role... not typically a good idea. The reason for bulkadmin here is to avoid the use of xp_cmdshell, which has obvious security concerns.With that said, the idea of the code existing in a file and potentially outside of the control of the DBAs makes the job of maintaining security on the SQL Server that much more difficult. What essentially is being done here is the SQL Server DBAs are being tasked with all the responsibility but none of the authority... they don't control who has access to the file.Case 3 can be handled by creating the stored procedure and using WITH ENCRYPTION. So long as the developer has neither sysadmin rights nor the ability to CREATE PROC with the database, the encryption angle is covered.K. Brian Kelleyhttp://www.truthsolutions.com/Author: Start to Finish Guide to SQL Server Performance Monitoring http://www.netimpress.com/

RE: Code Stored in Files Instead of Stored Procedures

seans — Fri, 24 Oct 2003 10:31:00 GMT

An interesting conceptual article with limited practical use. However, the author does caveat the baggage of EXEC commands. Using this requires explicit permissions for users at the table level since EXEC does not maintain ownership chains.The database design is no longer abstracted and must be continually published to a larger user community instead of a corporate data model.Supportability by an IT department is compromised. Performance can no longer be guaged or predicted since SP behavior would change. In a DB that resides on a shared server a poorly performing user built statement could adversely impact other systems.Not to mention all of the other benefit derived from the use of stored procs. No recompiles....

RE: Code Stored in Files Instead of Stored Procedures

fhanlon — Fri, 24 Oct 2003 07:35:00 GMT

I liked the article as it clearly put forward the concept. I'm not sure I see a business need at this time but it is an idea I'll keep in mind if circumstances warranted.

RE: Code Stored in Files Instead of Stored Procedures

FreeHansje — Fri, 24 Oct 2003 02:04:00 GMT

There are several arguments to store SP's outside SQL Server, not 1 of them is touched in the article. The reasons mentioned here are farfetched IMO.Kind regards,Hans Brouwer

RE: Code Stored in Files Instead of Stored Procedures

Andy Warren — Mon, 13 Oct 2003 04:13:00 GMT

I don't have access from where I am, I'll get someone to check.Andyhttp://www.sqlservercentral.com/columnists/awarren/

RE: Code Stored in Files Instead of Stored Procedures

5409045121009-7368 — Sun, 12 Oct 2003 20:37:00 GMT

Can you check the link please

Code Stored in Files Instead of Stored Procedures

Raghavendra Narayana — Sun, 12 Oct 2003 00:00:00 GMT

Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/nraghavendra/codestoredinfilesinsteadofstoredprocedures.asp