sage -
From: Adam Haskell
To: CF-Community
Sent: Monday, February 19, 2007 11:01 PM
Subject: Re: Storing images in DB.
What constitutes underload? I see this (or other abstract, vague terms)
constantly in the community and I think vague words like this can cause
confusion and may
raining in
> C# & ASP.NET 2.0 for ColdFusion Developers at
> ProductivityEnhancement.com
>
> ----- Original Message -
> From: Nick McClure
> To: CF-Community
> Sent: Monday, February 19, 2007 10:44 AM
> Subject: RE: Storing images in DB.
>
>
> We aren't
+1, always a good practice
On 2/19/07, Dinner wrote:
>
>
> Perhaps my bit of advice is to abstract resource references, so
> it's easy to switch it up? Eh...
>
>
--
---
Robert Munn
www.funkymojo.com
~|
Macromedia
On 2/19/07, Robert Munn <[EMAIL PROTECTED]> wrote:
> updates, and deletes. You think Flickr stores their images in a database?
> I
> don't know, but I doubt it.
I would almost bet that they do.
Seems like the hard core pr0n sites do it this way, as to the hard
core Ad sites. But I don't r
IMHO, storing images in the DB is fine, but it adds overhead. You can
mitigate the overhead with caching, etc. as Adam suggests, but you can't
eliminate it. Do you need massive scale? Scale consists of two things-
number of images and traffic level on your site. If you have millions of
images, you
e database tables, then you run into more issues.
> -Original Message-
> From: Adam Churvis [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 19, 2007 3:19 PM
> To: CF-Community
> Subject: Re: Storing images in DB.
>
> Nick,
>
> But RAM -- even virtual RAM --
On 2/19/07, Adam Churvis <[EMAIL PROTECTED]> wrote:
>
> I am disagreeing with *serving* images directly from the database. I'm
> suggesting the serve path to be:
>
> Browser Request -> IIS -> Image File -> IIS -> Browser
> Response
Ah. Sounds good. On a really heavy traffic site, I'd want eve
I think you are over-simplifying the web request portion a little, Doesn't
CF run via Jakarta and Tomcat now? Its been a while sense I've used the CF
server so I'm not familiar anymore?
> -Original Message-
> From: Adam Churvis [mailto:[EMAIL PROTECTED]
>
> I am disagreeing with *serving
iginal Message -
From: Nick McClure
To: CF-Community
Sent: Monday, February 19, 2007 3:07 PM
Subject: RE: Storing images in DB.
I didn't say disk caching, usually I cache to ram, either on the server, or
the load balancer.
> -Original Message-
> From: Ad
Get advanced intensive Master-level training in
C# & ASP.NET 2.0 for ColdFusion Developers at
ProductivityEnhancement.com
- Original Message -
From: Dinner
To: CF-Community
Sent: Monday, February 19, 2007 2:35 PM
Subject: Re: Storing images in DB.
I'm with Nick on t
I didn't say disk caching, usually I cache to ram, either on the server, or
the load balancer.
> -Original Message-
> From: Adam Churvis [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 19, 2007 2:57 PM
> To: CF-Community
> Subject: Re: Storing images in DB.
-Community
Sent: Monday, February 19, 2007 2:02 PM
Subject: RE: Storing images in DB.
Yes, never with CF, but I've done it before, and I've employed caching
techniques both on the server and on the load balancer to assist, but I'd do
that even it they weren't coming
I'm with Nick on this one. I love my pictures in me DB!
We've got a pure DB server, with a dedicated connection to our CF box.
With 20 people hitting it at once, it still served up pages pretty damn
fast.
Perhaps the webswerver itself was doing some caching-- there's this whole
"new" technology
OTECTED]
> Sent: Monday, February 19, 2007 1:30 PM
> To: CF-Community
> Subject: Re: Storing images in DB.
>
> Nick,
>
> Have you ever tried this *under load* with either a large number of
> images on a single web page, a single large image, or a combination of
> these?
e
To: CF-Community
Sent: Monday, February 19, 2007 10:44 AM
Subject: RE: Storing images in DB.
We aren't talking about static page images, those types of images should be
on the web server. He is looking for a way to ensure that the data and the
images aren't kept separate fro
.
> -Original Message-
> From: Adam Churvis [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 19, 2007 10:25 AM
> To: CF-Community
> Subject: Re: Storing images in DB.
>
> Listen to Rick. And picture in your minds the two very different pipes
> needed to r
Developers at
ProductivityEnhancement.com
- Original Message -
From: Rick Root
To: CF-Community
Sent: Monday, February 19, 2007 10:08 AM
Subject: Re: Storing images in DB.
It takes almost no work for an HTTP server to serve an image.
It takes a LOT of work for an HTTP server to se
It takes almost no work for an HTTP server to serve an image.
It takes a LOT of work for an HTTP server to serve a CFM file that pulls an
image out of a database, converts it to some friendly format and uses
cfcontent to push it out. A LOT OF WORK.
There are certainly cases where storing an imag
It has never been bad practice, that is what the binary data type was
designed for.
> -Original Message-
> From: James Smith [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 19, 2007 8:48 AM
> To: CF-Community
> Subject: RE: Storing images in DB.
>
> I think I h
+1
If we stored all the images in our database here, our database may get
distracted. ;-)
-Original Message-
From: Greg Morphis [mailto:[EMAIL PROTECTED]
Sent: Monday, February 19, 2007 5:55 AM
To: CF-Community
Subject: Re: Storing images in DB.
same here.. don't do it..
Stor
So I guess I'll be the lone man out, I think it is a good idea, Look at
applications like sharepoint. They store everything in the DB, word docs,
pdf files, images.
> -Original Message-
> From: James Smith [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 19, 2007 8:07 AM
> To: CF-Communi
same here.. don't do it..
Store the images on a server and the image INFO in the db (location,
date added, by who, size, file type, etc)
On 2/19/07, James Smith <[EMAIL PROTECTED]> wrote:
> > i have always been told that this is bad practice.
> > we have only used the db to store names, size, file
> i have always been told that this is bad practice.
> we have only used the db to store names, size, file type & locations.
I think I have too, but I am not sure why, or even if this still applies or
if it WAS bad practice for a very good reason in MSSQL 2000 but is fine in
2005 for example...
-
i have always been told that this is bad practice.
we have only used the db to store names, size, file type & locations.
~|
Upgrade to Adobe ColdFusion MX7
The most significant release in over 10 years. Upgrade & see new features.
24 matches
Mail list logo
