Reputation: 44268
We have an application, currently built on a SQL Server database with a "fairly" complicated data permission model.
At the center of our Application is an entity called Record
. Whether a user can see a record is based on the user themselves, the workgroup they're part of and the organisation they are part of.
In the diagram below, a logged in User
gets to see records to which they're directly assigned, or they're part of a workgroup to which the record is assigned, or they're workgroup is part of an organisation to which the record is assigned.
This is a bit of a pain in "SQL + NHibernate" land as there are some messy joins and unions being used to get the results I need. This is just one example of data which is permissioned this way in the application.
I'm just wondering how suitable this type of model is to a NoSQL/RavenDB object hierarchy and if there are any performance considerations / object model re-architecting that might be required.
Upvotes: 3
Views: 98
Reputation: 8444
I've wrote some code to try and work out the 1-to-many relationships from what is presented.
Is this how it is structured at the moment?
public class Organisation
{
public List<Workgroup> Workgroups { get; set; }
public List<OrganisationRecord> Records { get; set; }
}
public class Workgroup
{
public List<User> Users { get; set; }
public List<WorkgroupRecord> Records { get; set; }
}
public class User
{
public List<UserRecord> Records { get; set; }
}
From what I am understanding - a record comes in 3 forms:
And these would look something like, like a Table Per Hierarchy:
public abstract class Record { }
public class OrganisationRecord : Record {}
public class WorkgroupRecord : Record {}
public class UserRecord : Record {}
Upvotes: 1