Databases Reference
In-Depth Information
In the 2000 release, Microsoft spent a significant amount of time making sure that the underlying plat-
form was extensible, scalable, and generally well architected. I believe this was the right decision when
looking at the long-term use of this product. Focusing heavily on the platform did require that some end
user features be held until further releases. What we are seeing in the SSRS 2005 is a major addition of
some of the most commonly requested features. Some of these include multi-select parameters, sortable
headers, and a number of user enhancements. The major improvement comes with the new Report
Builder application. Report Builder allows users to easily create their own reports with a friendly
Microsoft Office-like interface.
If you are impressed by the capabilities of the .NET Framework, Web services, SQL Server, and ASP.NET,
you should know that by using these technologies Reporting Services takes data accessibility to the next
level. Microsoft is making good on its promise of making information available “any time, any place,
and on any device.” Reports may be designed using specific rendering formats and page sizes to sup-
port mobile devices. There are many other reporting tools with impressive capabilities, but none of
them is quite like this one.
This chapter will introduce several topics that will be covered in greater detail later in the topic. This will
be a high-level view of the need for and purpose, capabilities, and mechanics of SQL Server Reporting
Services.
Traditional Application Reporting
In many business applications, reporting is an afterthought. When designing systems, there is a great
deal of time spent on workflow, data elements, and the user interface. Systems take significant amounts
of time to design, build, test, and deploy. In the end, many organizations end up with a tool well suited
for collecting information and improving productivity. However, reporting is usually lacking. It seems
that people usually see reporting as a simple add-on that can be completed with relative ease.
The reality is that good reporting takes the same type of solid planning and design done in the original
application. You need to clearly define what it is the user is looking for, how he or she is going to use it,
and how often it needs to be available. Without proper planning, queries became complicated and diffi-
cult to support. Reports run slowly and are prone to errors.
To avoid these difficulties, you need a plan. In a perfect world, you would architect the database and
application around your reporting needs and would completely understand your users' requirements
before designing the system. In the real world, you may understand some of the users' needs ahead of
time, but chances are that new reports will be requested long after the other features are in place.
According to Frederick P. Brooks's
The Mythical Man-Month
, it's usually a good idea to learn from and
throw away your first few attempts at almost any design. I typically try to develop reports in stages,
realizing that the first attempt will be a prototype. My experience has been that when you gather the ini-
tial requirements, users will ask for a handful of different reports based on some specific criteria. After
the solution is deployed and people begin to use it, others will almost inevitably realize that they, too,
would like reports to help make their jobs as easy as their associates'. As users realize what kinds of
information they can get, they will find new and exciting ways to sort, filter, group, pivot, and slice and
dice their data — in ways they never thought possible. That is, until you show them the possibilities.
Search WWH ::
Custom Search