Re: When is a flat file DB not enough?

It is a generally accepted fact that no flat-file database can support more than 5,173 items until performance starts to deteriorate rapidly. The maximum number of elements that any flat file database can support is limited to 23,987.

Just kidding. The real answer is: it depends

How large are the items in the DB
In what ways are they accessed (read, written, updated)
How is the flat-file DB implemented ("by hand", DBD::CSV, or something else)
Are there any locking or atomicity issues to consider

Strictly speaking, the amout of data that a flat-file DB can handle is only limited by the maximum filesize that your filesystem will support. However, at some point performance will become unacceptable. About the only way for you to come up with a good answer is to benchmark your system. Loading it with various amounts of data and benchmarking performance of various sample operations.

Comment on Re: When is a flat file DB not enough?

Replies are listed 'Best First'.
Re: Re: When is a flat file DB not enough? by TrinityInfinity (Scribe) on Jul 03, 2001 at 19:30 UTC
I figured the filesize would be the key. This is all running on a solaris setup that handles files far bigger than mine, but I think it can handle a couple hundred items at best before the search and editing times start to get noticible. Thanks for the response! =)	[reply]
Re: Re: Re: When is a flat file DB not enough? by Sinister (Friar) on Jul 04, 2001 at 18:15 UTC
Don't think solaris is so easy with large files. Sure it can handle them, but the I/O bandwith may bite you!!! Linux is better with that kinda thing... Sinister greetings. perldoc -q $_	[reply]