UserImage.jpg
Bruno Costa dos Santos
12Views
8Comments
Solved
keeping 2 entities or creating a third entity that shares the same attribute
Question
Performance
Reactive
Best Practices
Application Type
Reactive
Service Studio Version
11.54.24 (Build 62760)

I am developing a library system that includes both employees and users, each sharing 5 identical attributes. I'm considering creating a 'person' entity to hold these attributes and establishing a one-to-one relationship with the 'employee' and 'user' entities, allowing them to have a person-type identifier. Would this be the correct approach, or is it better to maintain the two separate entities?

I have already searched how to create a form to save data in two different tables. However, I acknowledge that this solution is applicable to traditional applications 


outsystem-banco.png
0
0
31 Aug
Solution

Hello Bruno,

This is a very interesting question.

Both data models would work, I believe the decision just depends on the pros and cons of having one or another. Meaning which one is going to facilitate your queries to the database and your logic overall.

Let's say you have a screen where you'll list all the employees and another screen where you'll list all the users... Then there's no point of having a single table to store both of these concepts. Queries and screen rendering will take longer because you have more records in one single table. In this case, you should separate them.

However let's say that both of these concepts are strongly connected and you have a screen where you show both employees and users in the same listing. Or you have a timer that processes both employees and users personal data. It would be better for you to have a single table instead.


Assuming it's just to maintain 5 common attributes, if your app is quite simple and both concepts are not somehow connected, I'd keep them separated. But it all depends on your app and what you're trying to achieve.


Kind regards,

Rui Barradas

See solution in context
0
0
01 Sep

I understood your explanation, thank you!

0
0
01 Sep

Hi Burno,

It depends on the business context. What are the differences between employees and users? would employees also be the users?

Best regards,

Sam

0
0
31 Aug

Users are the people who borrow books. However, the relationship isn't between employees and users. Instead, it's a one-to-one  between people and employees, as well as people and users. The only use of the 'person' table would be to maintain these common attributes.

I'm not very proficient in English.

 

0
0
31 Aug

Replying to Bruno Costa dos Santos' comment on 31 Aug 2023 22:02:21

If so, I would keep it simple and have 2 separate entities of employee and user.

1
0
31 Aug
2023-10-21 19-42-11
Tousif Khan
Champion

Hello

This is totally depends on the requirement. for example - 

  1. If you are going to have employees as a user who will log in to the application and have their username, password then you need to have a relationship between them, if it is like an extension of attributes that your user table dosent have and you need to add sore information for the employee then you can create a one to one relationship with user entity.
  2. If employees are not users and they are just keep there for some use cases and dosent require login in that case you dont need to even create a relationship.
  3. If you want to create a one two many relationship that dosent make sense at this point if the user is an employee. because one user can loging to the application. so if one user is referenced to multiple employees, I dont think it make any sense.

I hope this helps
Thanks
Tousif Khan

0
0
31 Aug

Replying to Bruno Costa dos Santos' comment on 31 Aug 2023 22:14:30

Hello Bruno,

Please keep the comments in English so every community member can understand and participate in the thread :)

Thanks!

0
0
31 Aug
Solution

Hello Bruno,

This is a very interesting question.

Both data models would work, I believe the decision just depends on the pros and cons of having one or another. Meaning which one is going to facilitate your queries to the database and your logic overall.

Let's say you have a screen where you'll list all the employees and another screen where you'll list all the users... Then there's no point of having a single table to store both of these concepts. Queries and screen rendering will take longer because you have more records in one single table. In this case, you should separate them.

However let's say that both of these concepts are strongly connected and you have a screen where you show both employees and users in the same listing. Or you have a timer that processes both employees and users personal data. It would be better for you to have a single table instead.


Assuming it's just to maintain 5 common attributes, if your app is quite simple and both concepts are not somehow connected, I'd keep them separated. But it all depends on your app and what you're trying to achieve.


Kind regards,

Rui Barradas

0
0
01 Sep

I understood your explanation, thank you!

0
0
01 Sep
Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.