Question: I am making a webapp right now and I am trying to get my head around the database design.

I have a user model(username (which is primary key), password, email, website)
I have a entry model(id, title, content, comments, commentCount)

A user can only comment on an entry once. What is the best and most efficient way to go about doing this?

At the moment, I am thinking of another table that has username (from user model) and entry id (from entry model)

```
   **username    id**
    Sonic        4
    Sonic        5
    Knuckles     2
    Sonic        6
    Amy          15
    Sonic        20
    Knuckles     5
    Amy          4

```

So then to list comments for entry 4 it searches for id=4.

**On a side note:**
Instead of storing a commentCount, would it be better to calculate the comment count from the database each time when needed?

Answer: 
Your design is basically sound. Your third table should be named something like UsersEntriesComments, with fields UserName, EntryID and Comment. In this table, you would have a compound primary key consisting of the UserName and EntryID fields; this would enforce the rule that each user can comment on each entry only once. The table would also have foreign key constraints such that UserName must be in the Users table, and EntryID must be in the Entries table (the ID field, specifically).

You could add an ID field to the Users table, but many programmers (myself included) advocate the use of "natural" keys where possible. Since UserNames must be unique in your system, this is a perfectly valid (and easily readable) primary key.

**Update**: just read your question again. You don't need the Comments or the CommentsCount fields in your Entries table. Comments would properly be stored in the UsersEntriesComments table, and the counts would be calculated dynamically in your queries (saving you the trouble of updating this value yourself).

**Update 2**: James Black makes a good point in favor of *not* using UserName as the primary key, and instead adding an artificial primary key to the table (UserID or some such). If you use UserName as the primary key, allowing a user to change their user name is more difficult, as you have to change the username in all the related tables as well.
Even though it isn't in the question, you may want to have a userid that is the primary key, otherwise it will be difficult if the user is allowed to change their username, or make certain people know you cannot change your username.

Make the joined table have a unique constraint on the userid and entryid. That way the database forces that there is only one comment/entry/user.

It would help if you specified a database, btw.