> I have a site with a bunch of images/reviews. What i want is for > registered > users to rate and leave reviews themselves. I'm not sure how I should set > up this database though. > > Now, I have a table that holds the user info. Should I create a new table > for each image, which holds the user, and his comments/rating? > (this seems > rather bloated, and inefficient) or should I create a table > somehow for all > images and keep track of the user comments/ratings another way?
A lot of how you structure your database depends on the expected data that will populate it. How big will the reviews be? How many reviews per image? How many images? Creating a new table per image isn't unheard of -- at a company I used to work for, we estimated that we had around 25 million tables at one point in time. There were lots of factors that went into why our database was structured like that, but it worked for us. I would guess all you need is a table with the following columns: userid, imageid, comment, rating. The primary key should probably be across (imageid, userid), assuming that you're more likely to look them up by image rather than by user. Another question, though, is whether you'll be looking at just the rating fairly frequently. If so, you might want to separate the comments and ratings tables, since the ratings will probably be most efficient as an int of some sort, and the comments will be text fields. This would keep your most frequently used table having fixed-length, very short rows. If at all possible, I would try out several different structures, and run some test scenarios on each of them. Steve Meyers --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
