Question

I am busy practicing on designing a simple todo list webapp whereby a user can authenticate into the app and save todo list items. The user is also only able to to view/edit the todo list items that they added.

This seems to be a general feature (authenticated user only views their own data) in most web applications (or applications in general).

To me what is important is having knowledge of the different options for accomplishing this. What I would like to achieve is a solution that can handle lots of users’ data effectively. At the moment I am doing this using a Relational Database, but noSQL answers would be useful to me as well.

The following ideas came to mind:

Add a user_id column each time this “feature” is needed.

Add an association table (in the example above a user_todo_list_item table) that associates the data.

Design in such a way that you have a table per user per “feature” … so you would have a todolist_userABC table. It’s an option but I do not like it much since a thousand user’s means a thousand tables?!

Add row level security to the specific “feature”. I am not familiar on how this works but it seems to be a valid option. I am also not sure whether this is database vendor specific.

Of my choices I went with the user_id column on the todolist_item table. Although it can do the job, I feel that a user_id column might be problematic when reading data if the data within the table gets large enough. One could add an index I guess but I am not sure of the index’s effectiveness.

What I don’t like about it is that I need to have a user_id for every table where I desire this type of feature which doesn’t seem correct to me? It also seems that when I implement the database layer I would have to add this to my queries for every feature (unless I use some AOP)?

I had a look around (How does Trello store data in MongoDB? (Collection per board?)), but it does not speak about the techniques regarding user_id columns or things like that. I also tried reading about this in some security frameworks (Spring Security to be specific) but it seems that it only goes into privileges/permissions on a table level and not a row level?

So the question is whether my choice was appropriate and if there are better techniques to do this?

Answer 1

Your choice is the natural thing to do.

The table-per-user is a non-starter (anything that modifies the database structure in response to user action is usually suspect).

Row-level security isn’t really an option for webapps – it requires each user session to have a separate, persistent connection to the database, which is rarely practical. And yes, it is vendor-specific.

How you index your tables depends entirely on your usage patterns and types of queries you want to run. Is ‘show all TODOs for a user’ a query you want to support (seems like it would be)? Then and index on the user id is obviously needed.

Why does having a user_id column seem wrong to you? If you want to restrict access by user, you need to be able to identify which user the record belongs to. Doesn’t actually mean that every table needs it – for example, if one record composes another (say, your TODOs have ‘steps’, each step belongs to a single TODO), only the root of the object graph needs the user id.