Re: [OT][PHP4BETA] Enhancement Request

[email protected] wrote:
> 
> Addressed to: Szii <[email protected]>
>               [email protected]
> 
> ** Reply to note from Szii <[email protected]> Tue, 30 May 2000 23:02:57 -0700
> >
> > Application: Pulling .jpg files out of a database into the in-memory
> > file and then exported directly to the html.
> >
> > Workarounds:  1) Not putting image files in the database      2) Export
> > to a temp file and use <img src=x.jpg>        3) Separate .php file using
> > header(image/jpg) and use <img src=xxx.php?id=y>
> >
> > Just wishing for a "clean solution." Best bet so far is just calling
> > an external php file with ? params. Wish I could just call one of my
> > classes member methods to load/dump it instead of having to hack my
> > way with external files. 1 4line snippet of code for a whole file
> > gets kinda annoying.
> >
> > I can put it in the DB, get it out, but it's becoming a PITA to
> > display it  properly. Maybe someone can suggest a workaround?
> >
> 
> The best option I know of is option 1.  The only reason I'd consider
> leaving the image in the database is if other (non-web) programs also
> use the images from the database.  The consensus I've seen on this list
> is leave the image in a file, and store the filename in the database.
> 
> I don't think there is much the php developers can do with this
> problem, it is the way browsers work, and would require changes to the
> html standards.

There is a seperate http request for every object linked
in the page, whether those are inline images, flash movies, background
midi
etc.

The best option is to store the URL to the images, and store the images
on a
seperate server. That way your expensive DB connection isnt tied up
slowly
tranferring binaries and your dynamic content generation doesnt have to
pause
whilst you read, then temporarily save your image.

I have used all three approaches,
	option 2 is really only necessary if you are altering
	the image before sending it on (Adding "You are here" arrows etc)	
	
	option 3 solves the temporary file problem  at the cost of chewing
	up db connections that could be better utilized.

Everytime I've had to do it, it was done to satisfy some RDBMS
marketing related itch (see, we *can* store everything in oracle!)

I'm also still hoping for someone to come up with a good reason
for storing image data in a relational database. I can only think of 2
(neither of which is very good...)
	1) Security, extracting / editing & replacing is a lot more
hassle^H^H^H^H^H^Hauditable
	2) To make bogus scalability claims about your RDBMS
		(Remember the MS Terraserver - 1 Terabyte scalability!!
		99.9% non-searchable, non-indexable satellite photos and 0.1%
		usable data stored seperately)

one final alternative (I've read it, but not seen it work)
	use XML, store the image data as a base64 encoded string in the 
	document and take a huge performance hit on both client and 
	server that this 'clean' solution entails. 


sorry,
daniel