Yes, it's all about product listings. And I don't have separate objects for products and product listings ... that might take a bit to wrap my head around; it's certainly not the way people think here (we sell advertising, not products, so the Listing is actually the thing). It does have description, image, image_url, date, end_date, a boolean flag for on/off display (when it's end_date is past), etc. but only a few of the fields are required
Plus, it's all already working, or mostly working, or kind of working okay ... so the reasons for making improvements would be for code maintainability, easier extendability/cleaner code in thefuture, and easier understanding by the next guy if I got hit by a bus or got a better job offer, etc.
Since not many Listings get featured, that might actually be a place to zero in. Of course, since "features" appear in multiple places on the site (which is why there are multiple columns, more/less ... I didn't make that decision), there's quite a bit of code to alter to keep that working if we change the DB.
Images would be another place, perhaps, with a ; there are plenty of Listings that have no image. But, from that standpoint, there are quite a few that have no particular color, either, I think. Not even every listing has a price, which is probably unusual from most standpoints (quite of the items are negotiable in price and there's not even a starting price).
But to get back to the original questions:
- How worried should I be about many tables to replace One Big Table (and, therefore, many JOIN statements)?
- Generally speaking, how much logic should actually be done by the Query/DB engine and how much in PHP?