What would be an appropriate schema for this real life scenario? A Company C provides an enterprise product to organisations (O1, O2, O3... On) and their sub-organisations (SO1 ... SOn). The product offers the organisations a database of content which is created by C. This content is accessible by all organisations O1 - On and SO1 - SOn. 

At the same time an organisation O1 can create their own content that is not accessible by O2 - On.

These organisations, each have multiple sub organisations (SO1 - SOn). Content created by O1 is accessible to all suborganisations SO1 - SOn but content created by SO1 is only accessible to O1 and not accessible to SO2 - SOn

I have attached a sample schema that I think might work. 


Content created (either by organisations or company) is always represented by the same entity
Organisations can get their content specific content by org_id
Organisations can get the product content by root_org_id 
The Company C is represented as root_org, which is an organisation itself but has some special system privileges.


What would be an appropriate schema design to cater for the scenario mentioned? My main issue is how can Company C be represented in the schema as it is an organisation for all intentions and purposes but it also has special system / product privileges which no other organisations have. For e.g. creation of organisations (O1 - On) 



Example scenario - Company C has it's own administrative dashboard to 


create content and make it available to all organisations (O1 - On)
administer organisations (O1 - On) i.e. CRUD organisations 
provide support - sometimes login as the organisations (O1 - On) to troubleshoot and support
I think this is a case where a super type and subtype should be considered.

The fields that are specific to an organisation go in a separate table to the main organisation, and if there are any feels that are specific to say a sub-org they are stored in a separate table and joined for crud operations.

This approach means any validation for say addresses applies to all organisations, and the validations (access permissions) for sub types apply to all entities in the relevant table.

This approach also eliminated excessive quantities of null fields.

Another possibility is the parent-child model using the same table. This is where the table records a parent which refers back to an I'd of the same table. Only reason I suggest this as a possible option is as far as I'm aware the easiest way to enable unlimited sub-organisation levels. Querying this model is relatively complicated.