This is an architecture question, but its solution lies in ColdFusion and MySQL structure--or at least I believe so.
I have a products table in my database, and each product can have any number of screen-shots. My current method to display product screen-shots is the following:
I have a single folder where all screen-shots associated with all products are contained. All screen-shots are named exactly the same as their productID in the database, plus a prefix.
For example: Screen-shots of a product whose productID is 15 are found in the folder images, with the name 15_screen1.jpg, 15_screen2.jpg, etc...
In my ColdFusion page I have hard-coded the image path into the HTML (images/); the image name is broken into two parts; part one is dynamically generated using the productID from the query; and part two is a prefix, and is hard-coded. For example:
<img src"/images/#QueryName.productID#_screen1.jpg"> <img src"/images/#QueryName.productID#_screen2.jpg"> etc...
This method works, but it has several limitations the biggest listed bellow:
- I have to hard-code the exact number of screen-shots in my HTML template. This means the number of screen shots I can display will always be the same. This does not work if one product has 10 screen shots, and another has 5.
- I have to hard-code image prefixes into my HTML. For example, I can have up to five types of screen-shots associated with one product: productID=15 may have 15_screen1.jpg, 15_screen2.jpg, and 15_FrontCover.jpg, 15_BackCover.jpg, and 15_Backthumb.jpg, etc...
I thought about creating a paths column in my products table, but that meant creating several hundreds of folders for each product, something that also does not seem efficient.
Does anyone have any suggestions or ideas on the correct method to approach this problem?
use an Image table, one product to many images (with optional sortOrder column?), and use imageID as the jpeg file name?
Have a ImageClass table, many Image to one ImageClass.
Image ----- ID productID imageClassID (FK to ImageClass)
Use back-end business logic to enforce the some classes can only have one image.
Or... if you really want to enforce some classes can only one image, then can go for a more complex design:
Product ------ ID name ... frontCoverImageID backCoverImageID frontThumbImageID backThumbImageID Image ----- ID productID isScreenShot (bit) // optional, but easier to query later...
However, I like the first one better since you can have as many classes you see fit later, without refactoring the DB.