Lookups are based on a relationship. Portals are also based on a relationshjp. A portal uses a one to many relationship. A lookup copies the value from first related record, thus could be considered a many to one relationship even though the one could realy be many.
Ian, a LOOKUP (to me) is the ability to capture in time something that needs to be captured. The address (and other information) on an ORDER, for example would be something you probably want to be as it was at that point in time for historical (and probably legal reasons). If you just have an address listed as "related" and you change the parent address, this is not historically accurate on past orders.
In the time card solution, there is only ONE table. There is no "employee" table occurrence related to the "time_cards" table occurrence. So this solution with a self-join says, if you enter a record and set all the information (including the employee ID "k_ID_employee") the first time, you can save yourself some data entry time to "lookup" the information again based solely on the employee ID rather than retyping it for each new record for the same employee. This is great for historical reasons (lookup the info).
If you did have another separate table occurrence (employees) and used the "lookup" entry method, you would satisfy the "historical" usage as well.
I'd opine that the use of the single TO (as in this solution) and the use of lookup will be handy to save time up until the point where the employee has a name change or other information that is copied. The "lookup" will grab the FIRST related record (the first time card you entered for that employee). You'll have to make the changes manually each time there is a new record.
If you had that employee TO used for the lookup, then it would bring over the current information each time you enter the k_ID_employee.
Does that help?
looking @ fmp starter solution TimeCards and i tell you , there are some nifty details that i am using in my own solution that this one
helped me to see.
One thing that i just cant seem to understand though is why they would be using alookup from 1 TO to another with no portal?
can someone tell me why this would be necessary?
Thanks for that exhaustive explanation. totally get why now. IN the event i wanted more employee details,etc, then adding an employee table may be a benefit rather than having to put in "NEW" employee information for a new record.. At least that is what i understand from whatyou have explained.
Yes. an employee table would be most beneficial, Ian. You still want some things pulled with the lookup (to save retyping, and for that historical data).