Question

My app has authentication and for the user to be able to edit some row, he has to be authorized for it (be the “owner” of it). There can be more than one owner.

It’s not a trivial case “just create a owner – (1:n) – hasPermission – (n:1) – Table” because there are many tables (around 50), and the count will probably grow in time…

The only thing I have now is to create something like:

 Permission
    UserId --references Users table
    TableName -- name of the table he has permissions for
    RowId -- Id of the table row that he can edit

I can see a number of issues with this… (consistency, pulling all the rows he’s owner of into objects, etc…)

Is there some other pattern for this?

edit: As for the scale of the problem: about 50k users expected, 50 tables, around 100k rows max per table.

Answer 1

There’s a good old technet whitepaper from back in the 2005 era, about Implementing row and cell level security in SQL Server databases.

A lot of what they go into there may be overkill for your application, but it may give you ideas on how to implement simpler schemes.