I think we all have missed the opportunity to discuss horizontal scaling when it comes to links vs. blobs. If you store links in the data then you gain the ability to use edge caches, secondary file servers, web farms, file farms, network storage and all of those other high-capacity file services available for cheap vs. needing to buy new hardware and support a second MySQL server just to serve up image files.

IMHO it's more flexible to your application to store links in the database and let the files themselves come from systems organized around file services. It's possible to do so, and practical under certain conditions, to store files as data but you start running into the "economics of scale" once you go into "production". Consider this, you get better throughput from the database when it is both handling queries and pumping out the file contents? I suggest you let your other file-specific systems take care of the file/media/image traffic for you and leave your DB server to just handling queries.

Shawn Green Database Administrator Unimin Corporation - Spruce Pine

David Blomstrom <david_blomstrom@ To: mys...@lists.mysql.com yahoo.com> cc: Fax to: 05/20/2004 09:55 Subject: Re: BLOB's - General
Guidance PM

I'm confused. It sounds like you're basicallly saying that databases slow down as they grow bigger. That's logical.

But then you suggest that, when a database begins to get too big, BLOBs may be better than storing links.

I don't understand that. How can storing images as BLOBs be more efficient that creating a field that simply stores links to those images? Or am I missing something?