User Associate - Data model

0
I have question on data modelling: I have three types of users in my app: External User Type A External User Type B Internal User I have two objects called Event and Event Team. For every event record there will be multiple Team Members who are combination of external users and internal users. Event A   Member Name   User Type John Smith           External User Type A Richard Miller      External User Type B Jeff Scott              Internal Use Is it good idea to directly use the User/Account objects to create event members or create a custom object called “persons” and inherit the Account object to it?
asked
4 answers
0

Hi Sirinvas,

 

Are there any differences between Type A, B, and internal users? So for example, Type A has attributes that Type B doesnt, and Interal users have different attributes that Type A and B. 

Some questions you should ask yourself. Are there more internal users that external users? Do all users log into the system?

If there are different attributes for each type, then maybe a 1 - 1 association to a different table would be better. And have the accounts table hold all the attributes that apply to the three types. 

 

If this were me. If all three types of users have similar attributes, I would just add a "user Type" enumeration to the accounts table, to distinguish between the three different types, and then continue using the accounts table.

 

Here is a link to the mendix documentation for inheritance vs 1-1 associations\

https://docs.mendix.com/howtogeneral/bestpractices/inheritance-vs.-1-1-association

answered
0

Hi,

A similar question was raised and answered earlier: https://forum.mendix.com/link/questions/88570

This might help you.

Rene

answered
0

I've read all of the comments, and I think you are over-complicating your model, something I see a lot especially with newer RAD developers. For what you are describing, I would leverage the Account table and create one other Entity: Event. The "EventTeam" would be the association between "Account_Event", where an Account object can join many Events. Your Event Team would then be a an XPath or Microflow retrieve of all Accounts associated to a specific Event.

The ONLY reason you should create the EventTeam entity is if you have a need to capture data specific to that entity, such as date it was founded, or the number of events in aggregate they have finished, etc. Metrics specific to that event team would be a reason to have an entity that stores them, and you would build that one to many:many to many relationship you describe. Otherwise it is overkill.

answered
0

Austin,

Thanks for the response! There is no difference between these users except they all will be accessing the app. I like the idea of leveraging Administration/Account object and adding additional attribute with list of values to distinguish the users. So, based on your suggestion Event Team will become an intersection between Event and Account, is that correct?

Thanks,

Srini

answered