SQL Server Stored Procedures, Triggers, Functions, etc.

Typical Client Requirements
It is not uncommon for a firm using a vertical industry software application to begin to outgrow its native capabilities as the firm grows and develops its own specializations. It may be necesssary to track additional data, and to improve on customer responsiveness by adding automatic or semi-automatic data processes. Generally, clients need these structures to piggy back on the primary system's architecture, but to augment it in a separable way.

Solution Scenarios
New types of data means new data tables. It may even make sense to track such custom data in a separate database so that the primary application vendor can remain responsible for their own back-end. With the right network and database permissions set up, it is not a problem for data processing stored procedures to pull data from multiple databases even when they exist on separate servers.

Stored Procedures are not only able to go and get a complex view of data from multiple tables, but they can change data, and log its actions. They are the most efficient way to work with data in a modern database. They have available to them a rich and complete programming language. Built in to SQL Server is also the ability to interact with things outside of the database. It is possible to work with files, send emails, initiate backups, and in fact, call most server function libraries. By isolating a firm's complex business processes in the SQL Server layer, it is possible to provide a "thin client" experience for users. Whether a user interface is a custom application, a web page, or even a custom report, the heavy lifting is isolated to the server, which presumably has the power and memory to create the fastest result. They can be created to allow a user to run a process in a test mode and not really change data but yet to see what would have happened. This can be helpful in gaining user confidence and helpful for training.