| Pure .NET Stored Procedures [message #146929] |
Mon, 14 November 2005 15:12  |
maher
Messages: 5
Registered: November 2005
Location: malaysia
|
Junior Member |
|
|
We are considering the pros and cons of whether our client/server application should use a combination of stored procedure that are either native SQL or managed code based versus an approach where the stored procedures are only using managed code. Our database platforms will be Oracle (10GR2) and SQL Server (2005). Our understanding is that managed code is best used for complex manipulation that would be anywhere between difficult to extremely difficult for us to do in SQL (PL/SQL and T-SQL). The standard data manipulation of retrieve, insert, update and delete might still be best done as pure SQL stored procedures. Using managed code there instead would essentially create an unnecessary wrapper that can be done more efficiently as a pure SQL.
Our thoughts of still moving ahead with a complete managed code set of stored procedures are:
- Totally DB independent Code. We can move the same code from 10G to SQL2005 or vice versa;
- Our developers do not need to know T-SQL or PL-SQL.
At the very least we think managed stored procedures is a better approach that having the code in-line within the client application as the approach will give us:
- more efficiency as it is processed on the server (as it would for pure SQL based stored procedures);
- stronger security (as it would for pure SQL based stored procedures);
- easier code reuse;
If we did decide to go this route:
- Any limitations of utilization a pure .NET stored procedure system?
- What is the downside of this approach?
- Performance or other issues?
- Industry best-practices in this field? Is it so bad to go this way, or just rare?
|
|
|
|
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
