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 > > >
