Database design - how to implement user group table?

I want to make user group system that imitates group policy in instant messengers.

Each user can create as many as groups as they want, but they cannot have groups with duplicate names, and they can put as many friends as they want into any groups.

For example, John's friend Jen can be in 'school' group of John and 'coworker' group of John at the same time. And, it is totally independent from how Jen puts John into her group.

I'm thinking two possible ways to implement this in database user_group table.

1.

user_group (
id INT PRIMARY KEY AUTO_INCREMENT,
user_id INT,
group_name VARCHAR(30),
UNIQUE KEY (user_id, group_na开发者_如何学Gome)
)

In this case, all groups owned by all users will have a unique id. So, id alone can identify which user and the name of the group.

2.

user_group (
user_id INT,
group_id INT AUTO_INCREMENT,
group_name VARCHAR(30),
PRIMARY KEY (user_id, group_id),
UNIQUE KEY (user_id, group_name)
)

In this case, group_id always starts from 0 for each user, so, there could exist many groups with same group_id s. But, pk pair (user_id, group_id) is unique in the table.

which way is better implementation and why? what are advantages and drawbacks for each case?

EDIT: added AUTO_INCREMENT to group_id in second scenario to insure it is auto-assigned from 0 for each user_id.

EDIT: 'better' means... - better performance in SELECT/INSERT/UPDATE friends to the group since that will be the mostly used operations regarding the user group. - robustness of database like which one will be more safe in terms of user size. - popularity or general preference of either one over another. - flexibility - extensibility - usability - easier to use.

Personally, I would go with the 1st approach, but it really depends on how your application is going to work. If it would ever be possible for ownership of a group to be changed, or to merge user profiles, this will be much easier to do in your 1st approach than in the 2nd. In the 2nd approach, if either of those situations ever happen, you would not only have to update your user_group table, but any dependent tables as well that have a foreign key relation to user_group. This will also be a many to many relation (there will be multiple users in a group, and a user will be a member of multiple groups), so it will require a separate joining table. In the 1st approach, this is fairly straightforward:

group_member (
  group_id int,
  user_id int
)

For your 2nd approach, it would require a 3rd column, which will not only be more confusing since you're now including user_id twice, but also require 33% additional storage space (this may or may not be an issue depending on how large you expect your database to be):

group_member (
  owner_id int,
  group_id int,
  user_id int
)

Also, if you ever plan to move from MySQL to another database platform, this behavior of auto_increment may not be supported. I know in MS SQL Server, an auto_increment field (identity in MSSQL) will always be incremented, not made unique according to indexes on the table, so to get the same functionality you would have to implement it yourself.

Please define "better".

From my gut, I would pick the 2nd one.

The searchable pieces are broken down more, but that wouldn't be what I'd pick if insert/update performance is a concern.

I see no possible benefit to number 2 at all, it is more complex, more fragile (it would not work at all in SQL Server) and gains nothing. Remeber the groupId is without meaning except to identify a record uniquely, likely the user willonly see the group name not the id. So it doesn't matter if they all start from 0 or if there are gaps because a group was rolled back or deleted.