[tpm] Where to store file attachemnts

Indy Singh indy at indigostar.com
Mon Mar 23 14:51:30 PDT 2009


Thanks, that helped quite a bit to steer the design in the right 
direction.


Indy Singh
IndigoSTAR Software -- www.indigostar.com


----- Original Message ----- 
From: "Adam Prime" <adam.prime at utoronto.ca>
To: "Toronto Perl Mongers" <tpm at to.pm.org>
Sent: Monday, March 23, 2009 5:26 PM
Subject: Re: [tpm] Where to store file attachemnts


> I'd suggest not putting them in the database.  I personally would 
> probably put them in a normal directory on the site, not in cgi-bin. 
> It'd probably be wise to make the directory configurable.  At most i'd 
> include a path to the file in the DB, but if possible, i'd actually 
> rename all the files into a naming convention that identifies what 
> they are associated with.
>
> here's a link to a somewhat related thread on the mod_perl mailing 
> list:
>
> http://marc.info/?t=122271515400003&r=1&w=2
>
> which might be worth a read.  It's about images, but it applies to any 
> sort of binary you might be thinking of stuffing into a blob.
>
> Adam
>
> Indy Singh wrote:
>> Hi all,
>>
>> I am working on a forum-like web application that needs to allow 
>> users to upload and download file attachments.  The application uses 
>> Apache MySql and Perl.  A user would view a topic as a web page, 
>> similar to a Perlmonks node.  There would be links on the web page to 
>> any attachments.  The ability to view a given attachment should be 
>> limited to the user who owns it and the administrators.  Although the 
>> server is Apache, I want to have minimal reliance on Apache specific 
>> features like URL rewriting, etc.
>>
>> The design question I am wondering about is where to store the file 
>> attachments.
>>
>> The options that I can think of are:
>> 1) Store the files in a folder below the apache htdocs directory.
>> The links would then be URLS to the actual files.  When the user 
>> clicks on a link, the Apache server and web browser would deal with 
>> downloading or viewing of the file.  This is a simple implementation, 
>> the biggest disadvantage is that there is no security on the file 
>> attachment.  I suppose that you could add an effective password to 
>> the file by effectively encoding the password as part of the URL.
>>
>> 2) Store the files as mysql records.
>> The CGI application would handle all the fetching and output of the 
>> file data as well as checking permissions.  It would also have to 
>> deal with sending the appropriate CGI headers.  This would make the 
>> database a lot larger and slow down backup and restore.  It would 
>> also make it slower to make a snapshot and copy of the database for 
>> downloading to a test/development machine.
>>
>> 3) Store the files in a data directory in the cgi-bin directory.
>> The CGI application would handle all the fetching and output of the 
>> file data as well as checking permissions.  It would also have to 
>> deal with sending the appropriate CGI headers.  This would not affect 
>> the size of the database.
>>
>> Any comments or suggestions would be welcome.
>>
>> Indy Singh
>> IndigoSTAR Software -- www.indigostar.com
>>
>> _______________________________________________
>> toronto-pm mailing list
>> toronto-pm at pm.org
>> http://mail.pm.org/mailman/listinfo/toronto-pm
>
> _______________________________________________
> toronto-pm mailing list
> toronto-pm at pm.org
> http://mail.pm.org/mailman/listinfo/toronto-pm 



More information about the toronto-pm mailing list