Building a DB Structure

[AmrMohammed]

Greetings,

I'm developing an HRM application and such application including functionality like hiring decision, moving decision "for example, moving an employee from a department to another" etc. All such types of decisions done throgh the same Windows Form and each type of decision has a different data from the other one meaning for example hiring will say this employee will be appointed in this position, however, moving decision will say this employee will move from this department to that one, or that position to that one etc. so the data for each type of decision are different.

My question is, Do I put all the data for all decisions at the same table. Do I create the table that fits all kinds of data or I should and it is the best pratice to separate them to different tables?

[JorgeM]

Do I put all the data for all decisions at the same table. Do I create the table that fits all kinds of data or I should and it is the best pratice to separate them to different tables?

That's going to be challanging to answer because I do not think there is a right or wrong way of doing this. There are more or less efficient ways to design your structure. With a typical relational database, I typically try to normalize the data as much as possible. So, no I do not generally recommend that you use one table that holds all of your data.

[spectra]

If you need very often to show all those data all together, it will be some quicker if it is all in one table. If you need to display all employees separated by type of decision, then you should use separate tables, one for TypeOfDecision and another for Employees with foreign key to TypeOfDecision.

Generally, I would suggest to use separate tables, so you have more flexibility and easier maintaining in the future.