> I would NEVER let users design their own reports.

1) Every RFP and customer request asks about our (non-existent) report
generation capability.

2) Many customers are too small to have anyone qualified to write reports.

3) No customers want to pay us to write reports.

4) If we don't make customers pay for reports then the customer reporting
demand is infinite.

5) We fear that if we don't provide custom reports customers will take their
business to a more PHM-friendly company.

6) SHEs and PHMs want instant gratification.  This is not possible if they
have to rely on internal or external MIS support.  Besides PHMs resent
having to rely on lower life-forms like DBAs and C-geeks

7) The company is run by C-geeks.  They hate to write reports.  None of the
employees are CIS folks.  The C-geeks designed the schema.  They resent
paying DB developers.  They *hate* being mocked or lectured by these lower
life forms.

> First of all most users are not that sophisticated and savvy with
> database schemas to be able to design reports.

Well, they aren't savvy about SQL or databases.  Remember, *paying* someone
to write a report is a cost sink.  The whole idea is to put a lot of
parasitic MIS cubicle drones out of work.

> In order to generate
> good fast reports, the users need to be familiar with your database
> schema.

1) Yes.  So it won't be so good or so fast.  As near as I can tell
capitalism is about good-enough.
2) PHMR will provide a graphical representation of the schema.  When C-geek
derives a targeted report generator advanced documentation can be
hyperlinked to the graphical presentation.


> If you're going to do parameterized reports are you going to allow the
> users to write their own stored procedures?

Essentially, yes.  Tools like Access and Paradox come close to doing this
now.  The graphical query language (or wizards) would let users associate
any term that references dati in a query with an entry box on a form.  The
PHMR interpreter should have an optimizer that would determine whether or
not the query could be parameterized.  An option to "save query in database"
could result in a stored procedure.

> Why not include report building as a service? Give them x number of
> canned reports and build the rest as a service.

Because this does not result in happy customers.  PHMs have a very cavalier
attitude toward reports and an infinite appetite for them.  Besides, I
really don't enjoy developing canned reports at all.  Furthermore, the
canned reports are nearly useless.  No matter how big the set, the next
customer needs them customized all over again.