Re: Myth of the database independent applications (Was: Are you using PL/SQL)

On May 25, 1:33 pm, zigzag..._at_yahoo.com wrote:
> On May 25, 1:23 pm, hasta..._at_hotmail.com wrote:
>
>
>
> > On 25 mai, 00:43, zigzag..._at_yahoo.com wrote:
>
> > > I have worked so many projects using [the three-tier]
> > >architecture and performance has never been an issue.
>
> > Zigzag,
>
> > If you don't mind, and for better mutual understanding, would
> > it be possible to have a (very rough) idea of some metrics
> > for one of these systems ?
>
> > I'm notably thinking of system purpose and :
>
> > - size of stored data (in your prefered unit)
> > - size of daily data growth
> > - number of simultaneous users (peak would be most welcome)
> > - average and guaranteed response time for user interface operations
> > - number of transactions over your prefered time period.
> > (peak would be most welcome)
>
> > Really interested. Thanks much.
>
> > --- Raoul
>
> Performance is very complex subject with so many variables, In many of
> our projets there were a few people assigned to do performance
> measueremts on frequenetly used transactions by users and batch
> processes.
> Our database were up to 100GB large. 95% of our queries were indexed
> based. Systems are used by up to 100 concurrent users Hope it helps.- Hide quoted text -
>
> - Show quoted text -

I have had way too many issues and hassles with the Java/Hibernate crowd. With their insistence that the entire database be loaded into memory, (worked on my laptop with 50,000 rows, why CAN'T you load a 30GB database into a machine with 4GB of RAM?")

Their insistence on DB independence to the point that they insist MAX(user_id) +1 is a valid method of generating a sequence, until the ora-00001 errors come up and the DBA is asked to come up with a fix, "but we don't want to change application code."

Their insistence that any SQL that returns a resultset is the only SQL that can be run with more and more columns and tables added so that they only have to maintain 1 SQL statement in the application rather than (horrors!!!) maintain dozens or scores of separate SQL queries that each do something different. Of course then the DBA is asked to optimize a query that is basically SELECT * FROM EVERY_TABLE IN MY_SCHEMA and JOIN it to this LINKED_TABLE regardless of what data I actually need to display on the page. (It was fast in development and when the DB was small. Optimize it, please. Oh, and no don't change the query as we NEED all of these columns and we can't change the application code. But please make it go faster, certainly Oracle can do better than that!!!. And on and on.

Sometimes it's funny, really.

Anyway, time to go on another crusade, this time for enough disk-space to properly support a workable RMAN retention policy BEFORE some shortsited  bean counter decides that disk-space is expensive!!!! Received on Fri May 25 2007 - 12:54:00 CDT