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
Hi,
A similar question was raised and answered earlier: https://forum.mendix.com/link/questions/88570
This might help you.
Rene
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.
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