rootfixxxer (10/28/2010)
For example i have one section in the application where the users (workers) need to register hours for every working day, every user belong to a team, but the users can change of team, so the history doesn't be right if i use a normalized table....
If i go and try to check where the TeamB worked i'll get the wrong info because i have one row that tells me that it worked in ProjectA.
...
Actually the problem is that your existing design is not really normalized entirely. You are coding team as an "attribute" of the user in the same way as their name or date of hire. However, team membership is an "association", even if they can only be a member of one team at one time. Therfore, you need a User_Team table which relates a user with a team and also Start_Date and End_Date columns indicating when that membership was in effect. The same goes for things like User_Address, User_Phone (which would also include a column indicating "home" or "cell"), and User_Salary, because those things are also either associations or contextual over time.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho