Re: I would like to know how experts look at this problem

Hi Daniel ,

You are absolutely correct. I am not so found myself of the plan do execute a query that returns 500.000 rows to end-users,.

But it is what the customer wants and there is no other way.

As I explained before: end-users are presented with an overview and must have the opportunity to zoom in on the lowest detail. This can be done only with one query in Crystal Reports (a tool I have to work with).

No I do have quit some experience with several DBMS and Crystal reports, but not with Oracle.

These DBA's are very clever guys, but they told me that these queries are to much for Oracle databases in combination with 150 concurrent users. And that Oracle databases can not handle more than one transaction at on time. Well... than I start to wonder. So without going in to more technical details.. I think you can say something about that. And in fact: You already gave me my answer: "150 concurrent users is nothing for Oracle. 500,000 rows is nothing for Oracle".

I have tested the network and it can handle the amount of data.

But you are right... I have to work with these two DBAs. And I will have a talk with them. Thanks again for your reply.

Gregor.

"DA Morgan" <damorgan_at_exesolutions.com> wrote in message news:3E662B24.7639AB1E_at_exesolutions.com...
> Gregor wrote:
>
> > Hello all,
> >
> > I am a software developer, with some knowledge about databases, but I
would
> > like to know how experts look at this problem.
> >
> > I am developing a Management Information System for a customer. This
> > customer has 2 DBA's how disagree with me. This is the situation:
> >
> > My application retrieves it data from an Oracle database. There are 150
> > concurrent users.
> >
> > There are 3 different levels of users:
> >
> > 1.. Directors
> > 2.. Local managers
> > 3.. Shop managers
> >
> > There are 5 directors and 5 local managers. When one of these users asks
for
> > information, the query returns approximately 500.000 record (sorted
> > alphabetical!). The queries for the shop managers only return
approximately
> > 10.000 record (sorted alphabetical).
> >
> > Shop managers use the system daily and others use it weekly.
> >
> > The DBA's of my customer say that this system is never going to work,
> > because it is too much for the database server.
> >
> > I think that with the right hardware and the right configuration of the
> > oracle database it should work.
> >
> > What do you think?????????????
> >
> > Thanks,
> >
> > Gregor.
> >
> > P.s. I have been told that if oracle is processing one big transaction,
a
> > small transaction in the queue, has to wait until it the large
transaction
> > has finished. I know this is the case with MS Access, but I thought
Oracle
> > was more sophisticated (preemptive)?
>
> I think that if you were a good developer with sufficient knowledge to
build
> this system you would know that the information provided here is
inadequate for
> anyone to advise you. So I think a bigger concern than Oracle should be
one with
> respect to your skill set.
>
> 150 concurrent users is nothing for Oracle. 500,000 rows is nothing for
Oracle.
> Though I think any query that returns 500,000 rows to an end user is
dumber than
> dirt. Of course I'd start having a problem with any app. that returned
more than
> a few thousand rows to an end-user.
>
> The problem here is one of cost-effectiveness and cost of ownership.
Without
> knowing budgetary constraints it is easy to say what you are doing will
work.
> But if the budgeted hardware is a 500MHz Pentium III with 256MB RAM you'd
best
> quit while still ahead of the game.
>
> My advise to you is to provide real information to us before asking for
advice.
> And even more importantly you recognize that your success is totally
dependent
> upon the attitude of these two DBAs toward you and your code. I would
strongly
> suggest taking them out to lunch, getting them a few decent brews, and
> soliciting their advise. You could be 100% right and still be the wrong.
>
> Daniel Morgan
>
Received on Wed Mar 05 2003 - 17:14:02 CST