0

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 Profile via ProfileUser.

Reasons for implementation

  • Potentially useful for bigger clients with multiple employees needing access to Post(s)
  • 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 ProfileUser did 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 Post from User and adding new Profile and 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.

  • I would go by en.wikipedia.org/wiki/You_aren%27t_gonna_need_it and add it later. – Michael Durrant Oct 15 '16 at 22:58
  • @MichaelDurrant But if/when I do need it later, will it be very difficult to implement? It seems that I can put it off for now and worry a lot later, or go through the trouble of implementing it now and guarantee to never have to worry about it. – dvtan Oct 15 '16 at 23:06
  • 1
    @DavidTan if you implement it now you will have to always worry that you should have been doing something you really needed. You have a solution in search of a problem. Don't go creating a problem to feed to it. If you must, go publish a harmless paper, blog about it, or post it on github. Don't put it in working code that doesn't need it. – candied_orange Oct 16 '16 at 7:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.