I was toying around with the idea of creating a MySQL database for my comic strips. But while reading about image databases, I found that there are (at least) two fundamentally different ways to set up such a database. Option one is to upload the images into the database using BLOB. This is straight-forward enough. Option two is to load into the database the locations of the images, elsewhere on the server. Then the database just directs the browser to the images. I'm sure there are some database experts among you; which method do you think is faster? Which is better, overall?

Reply

See both of them work almost equally fast. You won't be able to tell the difference between an image being rendered from blob and one that's being loaded from a file. But I tend to prefer the former - i.e. BLOB. It is much easier to handle data & organize them better this way - or so I believe. The file-location based approach works fine too - but I don't really like the idea of having a bunch of scattered files with the database containing their paths. Some of the files can go missing and then all hell breaks loose. In the blob approach, either you whole database crashes due to some freakish reason - or you always have your pictures handy. If you maintain and optimize your tables from time to time then the blob approach is much better I think.

Reply

Blob sounds promising, but I do not like the idea of having everything inside the database...
In my experience I tend to get screwed over more with MYSQL then on the harddrive, so I'd just use MYSQL for the linkage . Like Micro said though...Their could become the problem of broken links...OR if you ever had to migrate to a different server...That'd be hell.

Though, I still suggest using the linkage method...Just make sure to keep everything tidy, and to avoid crashes

 

 

 

Reply

I too would feel more comfortable with images stored as images in the disk and databse containing the url's to them. In case you lose the database you don't lose the images.

But then again BLOBs would be a more elegant and neat way to do it. And not any more insecure if you keep frequent back-ups.

Oh, forgot this. Getting the images from the database (ie. the BLOB method), of course increases the database traffic more. So it might be in place to monitor how much traffic can the database server take compared to the web server.

Reply

Don't store your images in a database. Use method #2 and store them in a directory. One reason is the befored mentioned "when the database crashes you don't loose anything", but if you have a half way busy site, the added data in the database will cause the system to slow down and probably crash real quick, especially if the files are like 150k+ each.

If you must use a database, I would take a serious look at PostgreSQL instead. It may be slower than MySQL for most web requests, but if your going to be transfering lots of data, it will hold up better under load.

Still I recommend not putting image data into a database period and store the images in a folder.

Reply

I agree, I would never store my images in a database, there are so many things that can go wrong and "crash" your database. In some cases, you may not even be able to retrieve your lost data. When storing your images in a directory (like I do).

I have had MySql databases crash before, and if you start storing images that are over 100MB each, then your database is going to crash, and you'll wish you would have stored them in a directory.

If you are still stuborn, and want to store them in a database, make sure you have copies of them on your computer or on a CD.

Thanks,
Stusrud

Reply

I'd tend to disagree with the "blob data being more insecure because mysql is crash prone" way of thinking. I've written a school management software which handles well over 4000-5000 images of students+teaches+office staff sent in by various phototaking terminals spread around the campus - all instantly directed to a mysql server over the network (mysql 4.1.11 on RHEL AS 3). The transfer is instantaneous and the feel you get is that this image has been saved on a local drive. The network is a standard ethernet 100-Base-T network wired using CAT-5E UTP. Also whenever any student swipes his/her card at a terminal the image is instantly pulled out of the central server and transmitted to the local swipe terminal. This occurs around 3800times in a span of 30-40 minutes in the early morning checkin hours. Even with such a massive traffic you don't even notice a slight lag. Avg. picture size is 20-30K in jpg format. As long as your network is not suffering from any bottleneck anywhere this isn't a problem at all.

The system's been in place and running for past 7-8 months without any kind of crash whatsoever. For those paranoid about a crash - a very easy way out is to run a parallel mysql replication slave which performs automated incremental/differential backups of the main database whenever changes are made to it -- in effect creating a mirror copy of the master database on another server.

That takes care of the whole issue I'm not suggestging this method when you don't have your own hardware setup similar to what I mentioned above - what I want to stress on is that this approach is not as crash-prone as you might care to think.

Reply

Your comic strips are static. Once you wrote your history, you finished the work.
So, you don't need a database. A database is useful if you want to remove an image or add one.
For comic strips, you need to have the images on a directory, and create a webpage giving you all the images on the correct order, clicking on one of them to enlarge it.
So, for each comic strip set, you need a software to create the site (I mean a directory with everything in it and an index.html first page). xnview is free and dos the job fast and easy.
And for the next comic strip you have, you add a second directory on your site, and all the job you have to do is creating the very first page redirecting
comic-strip one to directory strip1/index.html
comic-strip two to directory strip2/index.html... etc.

Reply

From the XnView website:


I understand what you're saying and I think your solution might work, but XnView looks to me like an application for viewing images on your own computer, unless I'm missing something?

Let me be a little more specific with my needs. My comic strips are different sizes, formats, colors, and shapes (using transparent pixels). What I wish to create is a php page which calls each image from the database (or the link in the database) and displays it in a given area which expands as necessary when the title of the comic is clicked.

I've come to the conclusion that neither frames, nor iframes will be sufficient for giving me the kind of design control that I require. I've already accomplished my goals with javascript, but it is common for people to turn off javascript, so I am looking for a more universal solution. A database is just one possibility I'm exploring.

Here's my comics page, if that would help you understand my intentions better. Keep in mind that these are my first comics.

Reply

One quick tradeoff to keep in mind. Images in files are easier to bookmark and index. Search engines, for instance, like google's picture search, will probably like you better for having normal files with static, unchanging URLs. On the other hand, for some sites, that convenience is not what you want. If, for instance, you are charging per view or otherwise displaying images to particular account holders, or specifically do not want them indexed outside your site, you do *not* want static URLs and can serve BLOBs in response to POST requests.

This is not absolutely true; it is possible to set up your database app to serve images from blobs in a way which is search/bookmark/index friendly. It is just harder (no GET or POST requests, permanent URLs, etc). Given an equal amount of effort, file access will be easier.

Reply