The legacy e-commerce website I am working on at the moment uses the product id to name the image for each product. The image name and location are not stored in the database. So the product details page builds the product image name using the product id and reads it from the product folder.
New requirements have come through where they want to have 6 alternate sizes and some alternate views of the product (0 - 4 alternate views). I am not sure the current technique will scale very well. Looking for files of alternate images would be a lot more expensive then reading file names from a database.
The website is ASP .Net 2.0 and using SQL 2005.
At the moment I am thinking about having a new table to store productid, image path and type. So each product can have multiple product images. Then I will have to introduce a range of types for the different sized images and different logic around fetching the right type from the database.
What techniques do other sites use to multiple store images?
You touched on one way, use the product tables id as the primary key, to match the foreign key on the child table, witch would store the path to multiple images.
I would assume if you were to store, not sure if you thought of it, would to store the images in the database. But, with multiple images it would greatly tax your websites performance.
I would go with the way you mentioned. Anyone else want to chime in?
Filesystems definitely handle files better in an absolute sense. But databases are not a horrible option, especially if file sizes are under 5 or 10mb. They have a few advantages – mainly much easier to transport one big DB backup then lots of files strewn about the filesystem. You don’t need to worry about filesystem security, and not as much about other things messing with your artifacts. Finally, you can take advantage of transactions to write things to the database. ACID typically isn’t an option with filesystems . …
Insofar as CDNs and such go, that is still doable – just use the database as the original, backed-up store and distribute stuff to the CDN and such as requested.
I had been worried about over engineering the solution. It was good to hear others were thinking the same way I was. New database tables for image information and separate table for image type will allow me to handle all of the requirements.
Don’t think I will store the images in the database. It is something I had not thought of (which was what I had hoped for in asking this question, thanx!).
Not sure our database server would be up to the extra load.
A CDN would be cool. It is good to know that it can be scaled up if necessary. Just trying to get it working for now
