If a particular site will need to use a database, whether or not a searching ability is needed, then storing the site index in a database table (or two) would be preferable (barring that the additional access will not hamper regular trafic access).

In you case however, I would do as the man says and use a DBM file. Because the site index can be stored in one table (without TOO much redundancy), a database is a bit overkill - especially for a small site. In your case with a 'flat ASCII text 400K file', using a DBM file in replace might be a little overkill as well - but I say take the challenge and learn something new. Then, start researching relational databases.

What is a Berkeley DB file? Well, the easy answer is that generally speaking, a Berkeley DB file is a more efficient way of storing data then a simple ASCII 'flat file.' A Google search produced this online reference. Give it a look.

As an added bonus, I found this dusty archived node in the monastery: DBI vs MLDBM/GDBM_File, etc.. You will find a lot of good information from the many posts in that thread concerning which type of data storage is best (which always depends on the situation).

Minor correction - Perl does not speak to SQL - Perl speaks to a database through a driver, and the language that Perl uses is SQL.

There will always be memory and speed issues with whichever approach you choose to store your data. A 400K file is a speck of dust to modern PC's - so you have nothing whatsoever to worry about. Except the concept of scalability - what happens when that 400k file becomes 400 gigs? That flat file just is not going to be able to survive the browser time out.

Last note - this is NOT an easy task on the whole. Just remember that, because you are probably fixing to take a long journey, and it will get rough at times. Here is another thread for you to ponder: Searching module

Jeff

R-R-R--R-R-R--R-R-R--R-R-R--R-R-R--
L-L--L-L--L-L--L-L--L-L--L-L--L-L--