Traditionally the schema is very simple:
User <- Post
I have written the code for a
Profile model to be an intermediate:
User <- ProfileUser -> Profile <- Post
When registering for the website, a
User is created. A
User can create
Profile's, and multiple
User's can be attached to a
Reasons for implementation
- Potentially useful for bigger clients with multiple employees needing access to
- For casual/free-tier users, Profile linking can be made transparent, they don't have to know the feature exists
- I might need this flexibility "one day in the future" for reasons I haven't yet thought of
Reasons against implementation
- Complicates development, logistical overhead
- There may even be some performance overhead; I haven't profiled it but I expect the cost of two extra joins to be substantial.
- Liability of users complaining that another
ProfileUserdid something wrong and blame the website for primitive permissions control (I will not implement granular permissions or versioning/history). If this feature didn't exist, then their only option would be to share accounts, and the liability would be on them.
One thing that would help me make a decision: Is it difficult to add in this intermediate table later? In theory all it would take is detaching
User and adding new
ProfileUser tables in between them. I have no idea what this would look like in SQL, and don't know where to start looking or what this kind of operation is called. I'd like to hear from people with experience executing this kind of operation on a production website.
If it's relevant: I'm using Django and Postgres, I have no experience with raw SQL [yet] and Django migrations are still black magic to me.