Page 1 of 1
Subject Killer - Images stored in the database or as files
Posted: Fri Oct 22, 2004 1:12 pm
by terji
OK! Where to start?
I've been contemplating this issue myself but I can't seem to decide it on my own.
After searching the forum I notised that a lot of users have and still are posting on this subject.
I'm not going to provide a silver bullet here - so if you're one of those developers who actually is aware of what you're doing, this post will do you no good.
Anyway - let's get this settled!
PROs and CONs on storing images in a database and PROs and CONs on storing paths in the database and the images as regular files.
If you're storing the images in your database the performance is slow if you've got lots of images and heavy traffic (duh!). There's one I've seen posted on this forum. What's "lots of images" and "heavy traffic" ??? 1GB and 100+ queries a second... I'm confused...
When storing images in the database the file structure on the server is really nice!
C'mon - Give me a break... (OK - I've modified the posts a bit to fit my mood at the moment...)
Let's get serious! Which one is the one to go for - and in which circumstances...
Posted: Fri Oct 22, 2004 2:19 pm
by lostboy
There are also the condiserations of db space. Most hosted environments provide lots of disk space, but little db space...why fill the db with images when the disk is less costly to use?
Posted: Fri Oct 22, 2004 2:23 pm
by kettle_drum
Well my personal preference is to store them in the database as it prevents you having any read/write errors with directories as my code is generally run on several different systems. Plus your then only doing a single call to get all info, instead of getting the path and info on the picture from the database and then you get the file from a directory. I also find it more secure as i tend to have images that i dont want certain people to view and so i couldnt put all images in a directory anyway - a database just makes things easier for me.
Posted: Fri Oct 22, 2004 3:00 pm
by lostboy
So the real truth is that is may be application dependant.
Posted: Fri Oct 22, 2004 3:39 pm
by hedge
I currently store binary files in files, but have considered storing in the DB. However it doesn't seem DB independent, seems that each DB has a different way of handling binary data.
I have considered base64 encoding everything and storing it in the db as text, thus it could be written DB independent. Anyone ever done it this way? obviously it would be inefficient decoding each time a file was necessary but hopefully not that big of deal.
Posted: Fri Oct 22, 2004 4:21 pm
by timvw
imho, a filesystem is the best database for storing files
i don't think a 33% overhead (as generated by base64 encoding) is acceptable for storing files
if some more dbms manufacturers would support their own silly standards, we could all use BLOB :p
Posted: Sat Oct 23, 2004 12:32 am
by fractalvibes
I prefer to store things like images, docs, pdfs in the database. And I like having 1 reference to the object, which is a script that is responsible for fetching and displaying the object. Directory structures and SAN/NAS seems to change too often. Also, the objects can be compressed in the DB and various key values used to find it can be indexed.
2 Cents....
fv
Conclusion - Is that it?
Posted: Mon Oct 25, 2004 6:55 am
by terji
It looks like the conclusion so far is that it's the developer's preferred choise as long as traffic and storage limitations don't interfer ... Am I right?
Assuming I am right - let's say that we're running a MySQL database and are storing images directly in the DB. When have we reached the query limit where our application starts to be unacceptably slow? The disk space issue varies from one provider to the next, so I believe this query question to be the most important factor on whether to use DB images or not ...
Re: Conclusion - Is that it?
Posted: Mon Oct 25, 2004 8:27 am
by hedge
If a db schema is designed correctly, the size of the DB storage has very little to do with the performance. Not sure why people are concerned about disk space at this point when disk space is so cheap.
Posted: Tue Oct 26, 2004 6:37 am
by phpScott
I much prefer to store just the file name in the db and maybe a seperate column for the path. That way if someone changes the image but keeps the name it is very simple to just upload the new file.
I disagree with worrying about storing images in a db as I made a site that now has about 5000 hi-res jpegs and growing, without worring about the thumbs for each image, I haven't looked at the db stats for a while but I can only image that the size would be getting quite big and to go through and get all the images when that 1 client selects show all would cause the db server no end or grief.
phpScott
Posted: Wed Oct 27, 2004 8:53 pm
by fractalvibes
I suppose the ultimate answer is `it depends`. Personally I like the database method, as it abstracts some things like worrying about file paths that most certainly will change. My usage of this has been on DB2, and the DBA's encouraged it, as it's an enterprise-class DB that can handle it.
Either way, reference to the image/pdf/whatever is always by an autoincrement/identity value; we'll keep the filename in the DB, but change the actual filename to a generated value so there is no chance of a clash with files named the same thing.
fv