Don't store your images in the database. Store them on the filesystem
and store their path in the database. Anyone that tells you otherwise
is a stark raving madman :)
My system is very heavily used, and our pg_dump is only a few gigs.
Meanwhile our images/documents storage is well over a hundred gigs. I'd
hate to think that I'd have to dump and restore 100 gigs every time I
wanted to dump the newest data to the development database.
As far as how they actually get to the client machine, typically these
days people use web servers for this sort of thing.
Clodoaldo wrote:
5 Jan 2007 06:59:18 -0800, imageguy <imageguy1206@xxxxxxxxx>:
I think I know the answer,
If you know the answer please tell it as I have read some discussions
on the web and although I have decided on a solution I'm still not
sure about the best answer, if there is a best answer after all.
but if you don't have an "application
server" - ie a webserver, etc,
Yes I have an application server, the Apache server.
and many of the workstations/clients
that need access to the images but may not have access to a network
share,
network share? I don't understand. The images will be loaded by html
pages with the img tag like in <img
src="http://domain.com/images/xxx.jpg";>
isn't the database the only choice ?
No. It is one of the choices. The other is to store the images in the
file system, in a directory readable by Apache.
- or is there a postgresql function/utility that will "server" the
file from the file system based on the reference/link embeded in the
database ??
I think some procedure languages can read files. In this case what
would be the gain in introducing a middle man, the db server?
Regards,
![http://domain.com/images/xxx.jpg"](http://domain.com/images/xxx.jpg"){kind=link}