views:

473

answers:

12

I have 2 tables: Users and Roles, and I have a table that joins these together. The only thing in the join table is Ids that link the 2 tables.

What should I call this table? I've never really seen a good naming convention for this.

Conventions I've seen before:

  • UsersToRolesJoin
  • UsersToRolesLink
  • UsersToRolesMembership
  • UsersRoles

Ex:

Users:  
Id  
Name

Roles:  
Id  
Name  

TableThatJoinsTheTwo:  
Id  
UserId  
RoleId
+12  A: 

I would suggest simply UsersRoles, as that is what it holds.

_J_
Also remove the 'Id' column unless really required for some reason; Assuming that the lookups are more often done from User side, create a CLUSTERED PK on (UserId, RoleId) and another index on (RoleId, UserId) or just RoleId but including UserId.
van
A: 

Indeed, use table aliases and select the columns with same names apart with the AS selector.

e.g. SELECT user.id AS user_id

Ben Fransen
+8  A: 

I'd call the users table User, the roles table Role and the join table UserRoles.

By the way, the pk Id is not really necessary in a join table. Better make the UserId and RoleId together the pk or just uk (unique key) so that you can ensure unique User-Role relationships.

BalusC
That's what we do. It works fine.
peacedog
No Primary Key? Why? I though best practice was to always have PK?
Sonny Boy
@Sonny: Because you're usually never interested in a single row of a join table. It only unnecessarily costs one extra index.
BalusC
`(User, Role)` make a nice composite `PK` for this table. There is no need in creating a surrogate.
Quassnoi
@Balus Even if it's a high-traffic table where the links are changing thousands of times a day? In our app we have many of our links as objects that hold the PK so they can be deleted (or in some rare cases updated). I'm not disagreeing with you, it's just that we never thought of NOT having a PK. :P
Sonny Boy
`@BalusC`: a join table does need a `PK`, but not a *surrogate* `PK`. What it needs is a composite `PK` made out of the `FKs` it links.
Quassnoi
@Sonny If you want a primary key, you could simply make a multi-column primary key that spans UserId and RoleId (assuming that one user can't be added to the same role twice :)
Scott Anderson
We're talking about a PK in a **JOIN TABLE**. A join table doesn't need a PK. It doesn't represent a real world entity. It just links entities together. You already have keys in flavor of the UserId and RoleId.
BalusC
@Quassnoi and Scott: exactly that is what I was trying to tell.
BalusC
@BalusC: I would call the relation table 'UserRole' without s given that you suggest the original table names in singular form - for consistency.
van
@van: Depends. In our case the `s` at end of table name indicates a join table.
BalusC
+3  A: 

We have the same structure and call the link table UserRoles.

astander
Same here. I prefer plural names for tables (since the users table will typically hold a set of users, not a single user). But when you then link a user to the roles they are in, UserRoles makes sense.
Aaron Bertrand
Another good argument might be that many to many might need the Links in the name such that we refer to UserRoleLinks. Might work, but it is up to you X-)
astander
A: 

We've always used the names of the two tables followed by the word, 'Links'. So in your example our table name would be 'UsersRolesLinks'.

Sonny Boy
A: 

You could steal a page from Microsoft, and call it UsersInRoles.

Matthew Jones
+6  A: 

I'd call the link table this:

Remove_The_Surrogate_Primary_Key_From_The_Link_Table_Unless_You_Can_Prove_That_You_Really_Need_One
Quassnoi
+1 nice one, although there's usually a limit on table name length =)
BalusC
Yeah yeah yeah... In my case, I actually don't need it and will be using a composite primary key.
Josh Close
`@Josh Close`: Just name your table `UserRole` then :)
Quassnoi
+3  A: 

It seems like the mapping table is storing all the roles that each user is a member of. If this is correct I would call the table UserRoles.

This correctly (IMO) pluralizes the intent of the table rather than UsersRoles which just sounds odd.

akmad
A: 

I've always gone with something like : rel_user_roles or relUserRoles. Which table goes first usually just depends on where it is in the data model.

Alex Gandy
A: 

I have a convention which I find easy to see right away:

User
Role
User2Role
tster
A: 

This is the convention at my workplace:

UsersXRoles
Ewen Cartwright
+1  A: 
  • Table names should always be singular, that way later you don't have to be like "is it User or Users? What about things that end in an S? etc" (I would change this now if you just started the project)
  • The common convention would be: User, Role, and the xref table: UserRole.
  • The most important table, or the one that existed before goes first. This is specially true if the 'role' table has no real use outside user permission stuff. so UserRole makes much more sense than RoleUser.
  • I've seen things like User_X_Role or UserXRole as well, if you like the extra verbosity
Infinity
This is how my ORM works (and many others): collections returned are pluralized names of the entity.
RedFilter