Question

In my web application I will have users, each user will have albums, and each user will also have various users with permissions tied to an album. I can’t quite figure out if it would be more efficient to model my database with a bunch of tables prefixed by a user ID (i.e. 10384792_albums) or if I should have one table with a bunch of data inside (albums, which contains an id of the user). My previous example was about albums, but relatively the same thing would apply for users of users.

Keep in mind, an album itself will likely have a lot of rows of data itself for instance a name, description, date created, etc. I’m using MySQL and PHP. I suppose this is more of a question where I want to be pointed in the way of good design concepts, something that is scalar without sacrificing the speed of receiving data. Sorry if the question is a bit vague, I really don’t know quite where to start, any help would be appreciated.

EDIT 1: The users of users table is interesting. Think of it this way: for every user on this website, they will have their own unique login form to where their clients can access specific albums. The client will never log into my website using the same form that the users of my website do.

Answer 1

Something like this?

User table
----------
ID (primary key)
Username
(more columns with more user info)

Album table
-----------
ID (primary key)
AlbumName
(more columns with more album info)
OwnerID (foreign key to User.ID)

AlbumPermission table
---------------------
ID (primary key)
AlbumID (foreign key to Album.ID)
UserID (foreign key to User.ID)
(more columns indicating permissions)

With this layout, you have Users and Albums as entities and a table linking them (many-to-many linking table) which contains permissions. (This table is also sort of a meta-entity. By itself it’s essentially meaningless, but in the context of a User or an Album it contains information about the Albums that User can access or the Users which can access that Album.)

Each Album has a single User as its owner, and zero or more users linked in the AlbumPermission table who have various permissions associated with it.

Edit:

Based on your comment regarding tiered users, perhaps something like this…

Client table
------------
ID (primary key)
ClientName
(more columns with more client info)

User table
----------
ID (primary key)
ClientID (foreign key to Client.ID)
IsAdmin (boolean)
Username
(more columns with more user info)

Album table
-----------
ID (primary key)
AlbumName
(more columns with more album info)
OwnerID (foreign key to User.ID)

AlbumPermission table
---------------------
ID (primary key)
AlbumID (foreign key to Album.ID)
UserID (foreign key to User.ID)
(more columns indicating permissions)

The difference here is the addition of a Client table under which User records are grouped. User records now have a foreign key to a Client record so that each user is a member of exactly one client (Client to User is one-to-many), and an IsAdmin field indicating if that User is an administrative-level user for that Client (that is, has the ability to create/modify User records for the Client).

It’s expected that each Client would have at least one user. It doesn’t necessarily need one in this design, but it would make sense to create an initial User record when creating a Client (the User which is registering the Client).

You can expand this even further with more dynamic permissions for Client and User records, but this should be straightforward enough to get you going.