Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Code Stored in Files Instead of Stored Procedures Expand / Collapse
Author
Message
Posted Sunday, October 12, 2003 12:00 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, March 25, 2004 5:05 AM
Points: 5, Visits: 1
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/nraghavendra/codestoredinfilesinsteadofstoredprocedures.asp


Post #17197
Posted Sunday, October 12, 2003 8:37 PM
Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Wednesday, May 30, 2007 4:59 PM
Points: 672, Visits: 1
Can you check the link please


Post #83029
Posted Monday, October 13, 2003 4:13 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: Moderators
Last Login: 2 days ago @ 9:16 AM
Points: 6,784, Visits: 1,895
I don't have access from where I am, I'll get someone to check.

Andy
http://www.sqlservercentral.com/columnists/awarren/




Andy
SQLAndy - My Blog!
Connect with me on LinkedIn
Follow me on Twitter
Post #83030
Posted Friday, October 24, 2003 2:04 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Thursday, December 6, 2012 8:30 AM
Points: 879, Visits: 810
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
Post #83031
Posted Friday, October 24, 2003 7:35 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Friday, September 5, 2014 9:04 AM
Points: 2,184, Visits: 1,976
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
Post #83032
Posted Friday, October 24, 2003 10:31 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, November 5, 2003 12:00 AM
Points: 10, Visits: 1
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....



Post #83033
Posted Friday, October 24, 2003 3:03 PM


Keeper of the Duck

Keeper of the Duck

Group: Moderators
Last Login: 2 days ago @ 8:57 AM
Points: 6,634, Visits: 1,872
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
http://www.netimpress.com/


K. Brian Kelley, CISA, MCSE, Security+, MVP - SQL Server
Regular Columnist (Security), SQLServerCentral.com
Author of Introduction to SQL Server: Basic Skills for Any SQL Server User
| Professional Development blog | Technical Blog | LinkedIn | Twitter
Post #83034
Posted Monday, October 27, 2003 4:14 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: Moderators
Last Login: 2 days ago @ 9:16 AM
Points: 6,784, Visits: 1,895
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
http://www.sqlservercentral.com/columnists/awarren/




Andy
SQLAndy - My Blog!
Connect with me on LinkedIn
Follow me on Twitter
Post #83035
Posted Monday, October 27, 2003 3:27 PM


Keeper of the Duck

Keeper of the Duck

Group: Moderators
Last Login: 2 days ago @ 8:57 AM
Points: 6,634, Visits: 1,872
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
http://www.netimpress.com/


Edited by - bkelley on 10/27/2003 3:27:43 PM


K. Brian Kelley, CISA, MCSE, Security+, MVP - SQL Server
Regular Columnist (Security), SQLServerCentral.com
Author of Introduction to SQL Server: Basic Skills for Any SQL Server User
| Professional Development blog | Technical Blog | LinkedIn | Twitter
Post #83036
Posted Monday, October 27, 2003 3:55 PM
Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Wednesday, May 30, 2007 4:59 PM
Points: 672, Visits: 1
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.




Post #83037
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse