Schema for user roles/permissions

Question

I am currently creating an application where users can control minecraft servers from a website (which will interact with a plugin they install on their server). I am trying to think up a suitable design to allow each server to define their own user permission groups. In the end, there will be a predefined list of choices (stuff that my plugin will know how to handle) for each server to pick from and assign to a group that they create. I am aiming to have it so 1 single user on this website will possibly be able to have more than one group in a server panel, as well as the user being able to be assigned to more than one server panel.

Here is the database layout I have currently came up with:

Table: Roles     (will hold the predefined roles)
  Columns:
    serverTypeId (to distinguish between roles allowed for the 2 versions of minecraft)
    roleId       (the role's unique id, primary key)
    roleName     (some name to distinguish the role's purpose)

Table: ServerGroup (will hold the custom per server groups)
  Columns:
    serverId         (the server's unique id)
    groupId    (the server role's unique id, primary key)
    groupName  (name given to group, like Staff, Admin, etc)
    roleList         (a csv list of roleId's from the Roles table)

Table: ServerPermissions
  Columns:
    serverId       (the server's unique id)
    serverGroupId  (the server's groupId that this user belongs to)
    userId         (the user's id that is unique to the whole website)

Is there a better way to do this? This is the best way I have been able to come up with. I'm not the most well versed with SQL and am looking for ways to improve.

Answer 1

This looks like a fairly solid design, with one caveat. The roleList column in the ServerGroup table is what is called a repeating group within a column and should be avoided. Instead of cramming all the roleIDs into a single column, break that out into a separate table, which will serve as sort of a junction between Roles and ServerGroup.

Table: ServerGroupRoles (will list roles for each ServerGroup)
  Columns:
    groupID (foreign key to ServerGroup)
    roleID (foreign key to Roles)
  Primary Key: groupID, roleID

For each role that a ServerGroup has, there will be one record in ServerGroupRoles. The benefit of this approach to repeating groups is ease of searching and maintenance. Queries to check for the existence of a particular role for a ServerGroup will then likely be a seek on an index using equality, instead of a scan of the index using LIKE. In terms of maintenance, removing a role from a ServerGroup is a simple DELETE/WHERE statement rather than a needlessly expensive string manipulation.

Should your web application require that permissions be processed as a CSV string, it would be trivial to build the string from a query against ServerGroupRoles. Should the application change, however, you would not be stuck with the inefficiencies caused by the repeating group.