Mahavirsinh Padhiyar

It is depending on usage of functionality You can decide to use or not by looking at these advantages and drawbacks: Advantages Maintainability Because scripts are in one location, updates and tracking of dependencies based on schema changes becomes easier Testing Can be tested independent of the application Isolation of Business Rules Having Stored Procedures in one location means that there's no confusion of having business rules spread over potentially disparate code files in the application Speed / Optimization Stored procedures are cached on the server Execution plans for the process are easily reviewable without having to run the application Utilization of Set-based Processing The power of SQL is its ability to quickly and efficiently perform set-based processing on large amounts of data; the coding equivalent is usually iterative looping, which is generally much slower Security Limit direct access to tables via defined roles in the database Provide an "interface" to the underlying data structure so that all implementation and even the data itself is shielded. Securing just the data and the code that accesses it is easier than applying that security within the application code itself Drawbacks Limited Coding Functionality Stored procedure code is not as robust as app code, particularly in the area of looping Portability Complex Stored Procedures that utilize complex, core functionality of the RDBMS used for their creation will not always port to upgraded versions of the same database. Testing Any data errors in handling Stored Procedures are not generated until runtime Location of Business Rules Since SP's are not as easily grouped/encapsulated together in single files, this also means that business rules are spread throughout different Stored Procedures. App code architecture helps to ensure that business rules are encapsulated in single objects. There is a general opinion that business rules / logic should not be housed in the data tier Utilization of Set-based Processing Too much overhead is incurred from maintaining Stored Procedures that are not complex enough. As a result, the general consensus is that simple SELECT statements should not be bound to Stored Procedures and instead implemented as inline SQL. Cost Depending on corporate structure and separation of concern for development, there is the potential that Stored Procedure development could potentially require a dedicated database developer. Some businesses will not allow developers access to the database at all, requiring instead a separate DBA. This will automatically incur added cost. Some companies believe (and sometimes it's true, but not always) that a DBA is more of a SQL expert than an application developer, and therefore will write better Stored Procedures. In that case, an extra developer in the form of a DBA is required.

Hello this is Santosh from MUMBAI hello sir I m running my own computer education center at Nalasopara which is located at palghar dist from last 3 year I seen n after that I done a serve in this aria then after serve I came to know k so many students n young students are they who want to learn n dieing to get computer education but they won't because they can't afford that much fees. On that serve basis I want to give them that education by computer which is shape to there's career. N I have well expert faculty also. So I like your big hearts offer towards computer education. So as soon as possible plz reply me.