Review my database design
 

http://www.imgsync.com/data/img/1951...ase-design.PNG

Finally, completed. ;-)

Haris,

Would you provide a short narrative of what you are trying to achieve and how you expect the database to be accessed by users?

For example ... if you are planning to search on specific fields, you may want to add indexes to aide faster searching.

If you are looking to expand the database later to support additional content, then you may also want to re-evaluate how your data is normalized, etc ...

Good thinking bmicallef.

Quick things off the top of my head:
- There is no status table.
- Since you're using tinyint as your datatype for user_rank in your users table, you should do the same the the ID in your users_rank table. Tinyint should be more than enough, especdially if you make it unsigned since it'll go up to 255.
- In your comments table, isn't the comments_comments column a little redundant?

A signed int's range is -2147483648 to 2147483647, a unsigned int's range is 0 to 4294967295

In your case:
Check out MySQL AB :: MySQL 5.0 Reference Manual :: 9 Data Types for a more in depth explanation of all data types.

I am sure I'll have more than 255 users, 255 content, 255 ingredients, 255 comments and 255 ratings so i'll stay with unsigned int.

Thanks. :-)

I'm not sure if I'm the only one, but I'm having a hard time distinguishing the relationships. Seems like all the lines cross eachother.

Any way we could get a clearer model please?

First, let me make sure that my data types are correct. I have to make the relationship again if I change data types. :(

http://www.imgsync.com/data/img/7579...se-design1.PNG

A more readable version of relationships.
http://www.imgsync.com/data/img/1621...se-design2.PNG

Your users table needs some lovin'.

users
user_rank => tinyint(1)
username seems to be way too long, same with password and name
and i think the hashes password will always be the same length. so it's safe to use char(n)

Sorry, only had a quick second to spare.

Still there are missing the descriptions of relationships. Looking at your model, I don't know what kind of a reletionship is between USER and CONTENT.

Is a user creating a content, reading, rating, requesting a piece of content, etc? It is good idea to have the names of relationships. Like USER has ACCOUNT, USER belongs to GROUP, GROUP is managed by ADMIN, EMPLOYEE works in DEPT.

Quick question completly off the topic, what program did you use to create that db design???

Whatever it is, don't use it...

I suggest DBDesigner 4

fabFORCE.net