[thelist] database question

>ftp the file to the server with a different name, and rename it once its
>there. You can do this automatically with an FTP script, and since the time
>taken for a 'rename' command to execute on a half-decent server is waaay
>less than a second (and the OS usually locks the files whilst it renames
>anyway), the potential, nightmare problems of 'on-the-fly' uploading are
>circumvented.

Exactly. Or one can have a small subroutine in an admin script that does 
that with a click of a button from a browser. It is especially handy for a 
client that does not have FTP scripting ability or the upload is 
challenging enough for them.

>Having said this, I believe that a system such as MySQL is a better 
>solution for any site with anything over about 3,000 records to deal with.

For large databases, Postgres is even better (it is midway between *SQL and 
Oracle in robustness and very reliable, it is free--well, Oracle 8i 
Standard for Linux is still free too, but it is a behemoth that takes some 
260Mb), but I would raise the number of records in a flatfile to 20,000. 
All depends on how long the records are, how they are structured and how 
the search engine module parses the records. Some of my clients have 15,000 
record flatfile databases that are damn fast.

>a Flat-file and perl system, however, is very easy to build quickly, very
>easy to maintain, and can handle a considerable site load without causing
>any problems (I have proof!).

I have no problem believing you! :-)

>For people in a tight spot who need a
>functioning site within a few weeks, and who've never done SQL before, it 
>is the ideal solution. You should just start learning SQL as soon as you can...

Agreed. On the other hand, it may not be necessary if the SQL interface is 
built into a Perl application.