Database design for a rating system

Question

The application handles users and objects, users rate objects with 3 features (one rate per feature).

EDIT : the last sentence is unclear : by features I mean criterias shared by all the objects

How efficiently design a database for such a system ? What are the best-practices for designing a database dealing with a rating system ?

what I was thinking of:

Tables:

• users
• objects
• feat1rates
• feat2rates
• feat3rates

and relationships : An object has many

• feat1rates
• feat2rates
• feat3rates

A user has many

• feat1rates
• feat2rates
• feat3rates

Answer 1

Assuming you are not going to increase or decrease the number of rating features to rate, I would make a single table of ratings that would track the user, the product, and three columns (one for each feature)

So you have your Users table, an Objects table, and your Ratings table which has the UserID and ObjectID as a combined primary key, that way you enforce the one rating per object per user standard.

Answer 2

You want to encapsulate data in such a way that each table only contains information directly related to what it needs to deal with. Create linking tables to provide relationships between different sets of data (in this case, users and objects).

I would create the following tables:

User - the user's base information: login, password, user ID, whatever you need.

Object - the object to rate: its name/ID and attributes.

Feature - a table describing a type of feature, with some sort of feature name/ID. This may start with your three main types, but you could always expand/modify this. You can also customize which features each object will have available for rating.

ObjectFeature - a linking table for object and feature. Contains the primary key of each table, creating a many-to-many relationship between the two.

UserRating - another linking table of sorts, between the ObjectFeature and the User. Contains the primary keys of these two tables, as well as the rating assigned.

From a relational standpoint, this is a better way of organizing the data than what you presented. Through its design it makes clear how each set of data is connected and makes expandability (eg adding additional features to rate, having different objects have different features to rate) much cleaner.

Answer 3

Very strange design, I must say. Consider:

Object: ID, ...

// Provided features cannot be shared between objects
ObjectFeature: ID, ObjectID, ... 

User: ID, ...

UserObjectFeatureRating: UserID, ObjectFeatureID, Rating