Re: Why bother with a database if ...

In article <7LMx5.18$6f.954_at_pm02news.wcom.com>,

        "Michael J. Moore" <mNiOcShPaAeMl.j.moore_at_wcom.com> writes:

> scenario 1) I have a million session records in a database table and must
> read each record sequentially. I am using Parallel Server and the machine
> has, say, 8 CPUs.
>
> scenario 2) I have a million session records in a flat file and I read each
> one of them sequentially.

[snip Notes]

> Should I expect to see scenario 1. run faster because while CPU 1 is
> engaged in a read operation, CPU2 can be engaged in a seek operation
> therefor in scenario 1 the program requesting the data is served the data
> more quickly,
> OR....
> would scenario 1 only be single threading the I/O requests and therefor not
> benefit from the Parallel Server feature?

If you wrote a simple program to read the data sequentially from a file I would certainly expect it to be slower than using a simple query on an Oracle 8 partitioned table in a well-configured RDBMS.

My understanding of the partitioned table concept is that the query optimiser works out how many partitions of the table are required for the query and creates an appropriate number of parallel processes to do the reads.

To match or beat the performance of the RDBMS, you would have to write a more sophisticated multi-threaded program with data spread across disks (along the lines of Michael Long's answer). I am not sure there would be sufficient performance gain to justify the effort.

-- 
Regards,

Richard