SQL Server - separate database for reports?
The answer is: yes, there is a benefit to doing it. Reports on on operational database will use a lot of resources and will interfere with the performance of the operational system. Remember that database performance is subject to mechanical constraints (disk heads moving back and forth and rotational latency as we wait for the right sector to make its appearance under the head). You have two broad options for a reporting strategy:
- Replicate your database onto another server and move the reporting sprocs onto it. Reports are run off the replicated server. This is the least effort and can re-use your existing reports and stored procedures.
- Build a Data Warehouse that consolidates the data from your production systems and transforms it into a form that is much friendlier for reporting. If you have a lot of ad-hoc statistical reporting that could be done acceptably from a snapshot as of 'close of business yesterday' a data warehouse might be the better approach.
I think it much depends on the kind of SP you're running. If they are heavy and could effect other things running on the database server I'd move them. Otherwise I'd try and keep the close to the database they're actually reporting on, if find that much easier to maintain and keep track of. Just having the report close to the actual database could also affect performance but if your on a standard setup and not moving enormous amount of data that would be a tiny difference I guess.
I've also found this article useful.