On 7 Jan 2004, at 22:24, Rob Brahier wrote:
I made an online file manager using PHP and MySQL some years ago, and am
now embedding something similar into my office's database front-end. I
decided to store our files in the file system rather than the database
in order to keep the DB size low. A benefit of this is it takes less
time to restore a backup of the database than it would if I were dealing
with the extra gigabytes of embedded files (which I can restore on an
individual basis).
Incremental backups would certainly be smaller. The backup would spot individual files being changed, but being blobs in a table, the one (large) file in the database would have to be backed up for each change?
As for indexing, a lot of the document retrieval solutions out there
just go by metadata when you do a file search. Business class scanning
systems offer you the option of embedding user-supplied metadata in your
scanned files so adding your own keywords is an option. In my
experience you are better off going by just some supplied keywords and
metadata rather than the full text of a document because you end up with
more relevant results. The exception to this is when you are just dying
to know how many documents contain the word "pie". If you find that
this is the case then you obviously have the free time needed to build
some extra indexes... ;)
I think you're right.
Thanks for the input.
-- Regards, Steve.
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
