Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Code Stored in Files Instead of Stored Procedures


Code Stored in Files Instead of Stored Procedures

Author
Message
Raghavendra Narayana
Raghavendra Narayana
Forum Newbie
Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)

Group: General Forum Members
Points: 9 Visits: 1
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/nraghavendra/codestoredinfilesinsteadofstoredprocedures.asp



5409045121009-7368
5409045121009-7368
Say Hey Kid
Say Hey Kid (684 reputation)Say Hey Kid (684 reputation)Say Hey Kid (684 reputation)Say Hey Kid (684 reputation)Say Hey Kid (684 reputation)Say Hey Kid (684 reputation)Say Hey Kid (684 reputation)Say Hey Kid (684 reputation)

Group: General Forum Members
Points: 684 Visits: 1
Can you check the link please



Andy Warren
Andy Warren
SSCertifiable
SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)

Group: Moderators
Points: 7894 Visits: 2705
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
FreeHansje
FreeHansje
SSC Eights!
SSC Eights! (935 reputation)SSC Eights! (935 reputation)SSC Eights! (935 reputation)SSC Eights! (935 reputation)SSC Eights! (935 reputation)SSC Eights! (935 reputation)SSC Eights! (935 reputation)SSC Eights! (935 reputation)

Group: General Forum Members
Points: 935 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
fhanlon
fhanlon
SSCrazy
SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)

Group: General Forum Members
Points: 2379 Visits: 2275
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
seans
seans
Grasshopper
Grasshopper (12 reputation)Grasshopper (12 reputation)Grasshopper (12 reputation)Grasshopper (12 reputation)Grasshopper (12 reputation)Grasshopper (12 reputation)Grasshopper (12 reputation)Grasshopper (12 reputation)

Group: General Forum Members
Points: 12 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....



K. Brian Kelley
K. Brian Kelley
Keeper of the Duck
Keeper of the Duck (7.3K reputation)

Group: Moderators
Points: 7340 Visits: 1917
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
@‌kbriankelley
Andy Warren
Andy Warren
SSCertifiable
SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)

Group: Moderators
Points: 7894 Visits: 2705
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
K. Brian Kelley
K. Brian Kelley
Keeper of the Duck
Keeper of the Duck (7.3K reputation)

Group: Moderators
Points: 7340 Visits: 1917
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
@‌kbriankelley
5409045121009-7368
5409045121009-7368
Say Hey Kid
Say Hey Kid (684 reputation)Say Hey Kid (684 reputation)Say Hey Kid (684 reputation)Say Hey Kid (684 reputation)Say Hey Kid (684 reputation)Say Hey Kid (684 reputation)Say Hey Kid (684 reputation)Say Hey Kid (684 reputation)

Group: General Forum Members
Points: 684 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.





Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search