Re[2]: db engines VS flat files

Allow me to interject something from antiquity as well.

I have the displeasure to work with an old database called TurboImage from HP. I would place it somewhere between a flat file and a real database engine. The reason being that it stores data in flat files that are accessed via turboimage intrinstics (read that as functions). It is kindof like a database engine as it handles data as tables and has a degree of referential integrity, but the two biggest problems are locking and someone changing the file layout. Locking does not exist as we know it in the Oracle world, it's basically 'he who gets there first wins', also read consistence and rollback were not design considerations. Worst of all is the datafile headers, which if someone changes them without re-compiling all of the programs involved, well you get the picture production problems out the wazoo.

Don't do it, PLEASE!

Dick Goulet

____________________Reply Separator____________________
Author: Jared Still <jkstill_at_cybcon.com>
Date:       9/10/2001 6:40 AM

In addition to Greg's comments I would like to add that anyone suggesting flat files for 50 gig of data is probably not at all familiar with database technology.

Perl is an excellent language for manipulating data, but it is not a database engine. 50 gigs of data is totally unmanagable as flat files.

Personally, were someone to suggest that to me I would have to bite my tongue to contain the laughter.

At the very least, something like MySQL should be used.

For a look at what is available in the way or database interfaces for Perl, have a look at:

http://search.cpan.org/Catalog/Database_Interfaces/

Jared

On Sunday 09 September 2001 12:40, agc wrote:
> I would like to know your opinion about the developments under for
> example perl for handling large amounts of datas (sets of flats files
> larger than 50 gigs) vs the option of using oracle for exmaple for doing
> the same task, wich would be more eficinet? why? cheers
>
> The information contained in this communication is
> confidential, is intended only for the use of the recipient
> named above, and may be legally privileged. If the reader
> of this message is not the intended recipient, you are
> hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited.
> If you have received this communication in error, please
> re-send this communication to the sender and delete the
> original message or any copy of it from your computer
> system.
> Please do not re-send by any reazon in any way or form any of the
> informatino here contained.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Jared Still
  INET: jkstill_at_cybcon.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: 
  INET: dgoulet_at_vicr.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).