Code Stored in Files Instead of Stored Procedures
-
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/nraghavendra/codestoredinfilesinsteadofstoredprocedures.asp
-
Can you check the link please
-
I don't have access from where I am, I'll get someone to check.
Andy
-
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
Greetz,
Hans Brouwer -
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.
Francis
-
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....
-
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 Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
K. Brian Kelley
@kbriankelley -
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.
Andy
-
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 Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
Edited by - bkelley on 10/27/2003 3:27:43 PM
K. Brian Kelley
@kbriankelley -
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. -
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.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply