imagine a large system where pdf-files are accessed by clients a lot.
say 1 pdf file is access per second on average.
also say that your database is on a machine separate from the
webserver(s) (as is common).
do you really think its a good idea to pump the pdf data from the db
each time it needs to be accessed?
it may seem easier to do this as you then would not have to replicate
the physical files across the webserver machines, but i would not say
that the slight increase of ease is worth the added load to the db and
the network.
following your reasoning, you'd also store all images in the db so that
you don't have to replicate these either?
what is unsafe about having a pdf file on a webserver (not in a place
where the httpd can access it of course)?
alec
[EMAIL PROTECTED] wrote:
I have to disagree with most, I would store the entire file in the
database, metadata and all. Better security, if you have a backend
database, it's much harder to get the data than pdf's sitting in a
directory on the webserver. Plus if you ever want to scale to a
multi-webserver environment, the db storage works great.
On Wed, 7 Mar 2007, Ed wrote:
On Wednesday 07 March 2007 21:26, Alexander Lind wrote:
I would put the pdf as a regular file on the hd, and store the path to
it in the db.
Meta data could be things like the size of the pdf, author, owner,
number of pages etc.
Storing binary data from pdf:s or images or any other common binary
format is generally not a good idea.
Alec
Thank you all for your help. I get the gist of things... don't store the
binnary, store the path to it and details of it.
Thank you all for your quick response.
-Ed
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
