Re: Very Large DB

For performance I would recommend the latter approach. I wrote a faxing service where I used a database to organize the data about the faxes, but I kept the text information and the resulting .TIF files in separate disk devices. The database contained file paths for the related files.

The problem you'll have in your design if you structure a database as a front end is retrieving the data. SQL*Net would probably be the protocol for retrieving the relational data, but you would have to have NFS or other shared disk protocol to get to your externally stored data. Triggering an FTP or using a proprietary socket for data download is another way.

You might consider prototyping both approaches with 1% of the expected data. That could get you out of the religious wars.

--Bob.

Jason D. Weil wrote in message <35184524.4F7DCACF_at_mcs.net>...
>I am leading a development effort that will result in a multi-billion
>row database, on the order of 400GB. About 80% of this database could
>properly reside in a single partitioned table, each row being fairly
>small. There is some contention within our organization as to whether to
>implement this as a completely relational database (using Oracle 8), or
>to implement the largest table as flat files and use Oracle as a front
>end for accessing these data. Does anyone have experience with this type
>of problem? Have you had success with either of these approaches, or is
>there another, better, candidate?
>
Received on Wed Mar 25 1998 - 00:00:00 CET