I don't see it as difficult as it seems:
So, a person is a person and if a person enters your records you'll have his record as person.
Now an IdCard is a Card (registered as a number or any other unique value).
If a person (ID=1) has a Card (ID=37) when the person starts working it's registered that person 1 (who has Card 37 - not registered) started working @ $H and ended @ anytime.
Supose that person 1 is Employee 40.
It doesn't matter if is Internal or SubContracted Staff. You'll analyse that later.
If this person leaves job, he/she keeps registered as person.
You delete Employee 40, deactivate it with a %Boolean (Active) or You copy this record to Inactive Employees, but you keep track on everything.
The card 37 will go then to person 900.
Am I right ?
Nuno
Teoman Haliloglu wrote:
Hi Nuno,
All the talk might seem theoretical, but in fact it's not, and for me, this is a vital part of an application design...
In our workplace we have subcontractors. After a subcontractor hires a worker and brings him to our workplace, we issue him an id card (proximity card actually) to record his working times electronically. We also define the worker in our system as a staff of the subcontractor.
We do the same for our own staff. Of course we keep some more information for them...
If a worker leaves a job, we take his id card back. Issue to someone else as needed.
The turnover in the industry is really fast, you see the same worker changing workplaces twice in a week sometimes.
We keep "who worked for who and when" data and issue the cards accordingly. But we need to keep this data somehow, as the weekly payment to subcontractors are based on the working times of their employees.
Also the type of work the worker is doing may change in time or from subcontractor to subcontractor... This is also an other basis for payments...
We have two choices to retrieve that information when needed:
1. To keep "who worked for who and when" data together with the card issues for employment records. Also to keep "who (which card) went in /out of our workplace and when" info. Then unite these information together to retrieve a particular subcontractors' hours of work. Beleive me, this is a real pain in terms of performance in a relational database.
2. To keep "who worked for who and when" data together with the card issues for employment records (mainly for archiving purposes). Also to keep "card number, subcontractor, person, typeofwork" data for every transaction at the doors depending on the latest situation at the moment of transaction.
So what Denver and Peter suggest suits better into this situation (1rst choice) although a bit harder to implement... Instead of inheriting the Person class, they say it is more suitable to inherit PersonEmployment class as SubcontractorPersonEmployment, OurfirmsPersonEmployment etc, which definitely is a better idea...
I beleive I wont keep PersonEmployment class abstract as I'll need to span it as Peter suggested.
Still watching the conversation with interest...
Best wishes, Teoman
"Nuno Canas" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
I think the data model i use in real life can give a bit help on this:
Entity (the main one) Person (Extends Entity) Customer (Extends Entity) Employee (Extends Person) Supplier (Extends Entity) CustomerContact (Extends Person) (etc.. I can post more if you like)
So Every new ID goes to Entity. Person has an index (for me) on IDCardNubmer so if somebody has been registered as a Customer Contact and we want to hire him, when you try to register you'll get an Error. What you have to do is Create one Entry in Class Employee referring the Person.%Id(), Then Erase it from CustomerContact.
Am I wrong ?
Nuno
Peter Cooper wrote:
Denver
Rather than answer your strawman argument ad infinitum, permit me to
make below the substitution that I specified above.
I do not think it is strawman - this is a real problem ie how to associate completly different classes to a single class in an efficient manner
Lots of different class of "entity" can "work" on a project Lots of different class of "treatments" can be given to a patient (drugs, surgery, physio) etc etc
The key problem is given a one ("entity"/"patient") find all the many's that are associated with the one
your suggestion is to create procedure that scans each of the assocations separately, construct a temporary sorted structure will work but maybe not the most elegant method
Also I think we have been getting theoretical without trying it out some of the implementation issues are that you cannot (I believe) have a relationship between abstract classes - relationships can only be between persistent classes - I know you will disagree, I do to, but that's the way it is implemented
Also the SQL/Indexing for searching traversing a collection=array/list is not efficient
give me a bit of time to play around with it
Peter
