[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