This almost sounds like a homework assignment.
If each category has the same fields then you'll probably want to use the same table in which case you'll need to add a category field to the table beyond what you've listed. The category field would most likely be an id and a foreign key to a category table, containing the category name and id.
Whether the images are stored in the database or somewhere else will depend on how this data is to be presented and maintained.
The easiest is to store the image as an file and have a url/pathname to the file stored in the database for each image. This does lead to potential problems where the images are moved or deleted. but the database records still refer to the original image that's no longer there. You'll also have to deal with how to structure storing them on the disk so that multiple images that have the same name don't overwrite each other. Since you have an ID column in the database it may be helpful to include this id in the image filename so you can easily associate which images go with what article.
Storing them as a blob in the database is a good way to make sure you keep the image with the rest fo the information but there are the storage issues of whether the image sizes are larger than what the db can hold, although this is probably not an issue.
Main Topics
Browse All Topics
by: dqmqPosted on 2007-09-14 at 11:07:33ID: 19893795
1. One table for magazine
One table for common fields of all categories
One table for each category that has unique fields (maybe you don't have any)
One table for jpg references (to also support 0,1, or >2 images per category)
2. Yes, put images in a folder. Name them however you like, but a standard seems like good idea.