Points to consider for Report Database.

Ok..ok, I'm trying to get some comment/ insight on what things to consider during developement of a
Reporting module with a Reporting Database. For those who had face problems, been doing something like this, maybe you like to share a tip or two.

Project:

Developing ASP/ ASP.NET applications through DNSless connection with either OLE or ADO drivers to a SQL Server Report Database. Users will login in the browser to view reports of their choice. Not using any OLAP cubes. It would simply be callling SPs and query the tables for data and displaying it in cuztomize HTML report formats. And of course with good indexing.

Project scope:

Enterprise/Factory scale -so to assume Reporting DB size easily over 50-70 GB.

QUESTIONS:

1. How many users can concurrently login to view reports? A rough estimate would be? Is there any unit of measurement to determine the number?

2. What are the best practices- in DB design and and on application development for this project case?

3. What are the hardware concerns/specs ( best/minimum recommendations)? Would network traffic play a role here?

Thanks in advance for sharing your comments.It depens on what kind of database is but anyway:

1. Quantity of users depends on database and application design (respond time, etc.)
2. Best way - to create datawarehouse
- denormalize tables (less joins)
- a lot of indexes
- access only by sp
- you could create a fake cubes (I did it - it works even better than MS cubes for my case)

3. Ask for more and get something better... ;)sql