Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

BLOB or File? 1

Status
Not open for further replies.

JRBeltman

IS-IT--Management
Joined
Feb 5, 2004
Messages
290
Location
NL
Hi all,
I am reading an awful lot about the problems with blob and most feel having files is better for images, but what are the pro's and conns of both?


JR
(In need of a cool signature)
 
If you are storing content in a database server, my recommendation is generally that you store images in files on the server's filesystem and the names of the files in the database. This reduces overall complexity of your site and allows your web server to do the serving of images without having to invoke a PHP script.



Want the best answers? Ask the best questions!

TANSTAAFL!!
 
This question has been asked loads on this forum, sleipnir always argues files, I agrue database for scaliability reasons. I dont think there is a correct answer.Have a search and read the various comments
 
Hiya,
Yes I have seen many an article about how to work both solutions but no distinctive advise on which one to use or why (as far as I have found going through at least 50 postings)?

Anyway it seems most people end up using files, so why do you agrue blob?

JR
(In need of a cool signature)
 
Basicly I've spent a lot of my life creating scaleable solutions, web being no different. If you use files you are limited to one server and so if you run out of steam on the server you can't simply roll a new one in (scaling out). You also have to create some kind of index system as unix and windows have limits on how many files you can have in a directory. A DB on the other hand does all this stuff itself.
If you did want to spread flles around servers you would have to know which one it was on and be able to retrieve it over a network (not hard but you would have to do it).
I could go on for ages (and have done elsewhere !) but in MY opinion the performance hit you will get by using a DB (even then if it's a common image it may get cached) is ofset by the programming ease and ulitmate maintenance issues of using the file system.
Final point I dont think that mysql is a good db to store images in and store then gziped !
 
Thanks,
that was indeed what I was after and has got me thinking.



JR
(In need of a cool signature)
 
On the other hand, in order to stream the images out of the database, your site requires greater code complexity (to write scripts to fetch the data from the database) and more server resources (to run the database, to run the script and to stream the data from the database server then to the connection).

It really depends on how large your system is going to be. The filesystem limits for Linux's ext3 filesystem is 32768 files in a directory. I suppose if your image library were expected to grow larger than that, storing the files in a database would look attractive.

But you could accomplish the same workaround by simply calculating subdirectory names using a hash.



Want the best answers? Ask the best questions!

TANSTAAFL!!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top