| Except Clients tend to be businesses with EINs instead of SSNs. So there really are Clients. But sometimes in accounting an employee is a vendor because you need to draw a check outside of the normal employee employer relationship.
I am trying to normalize this structure. Maybe I shouldn't. I would love to hear other people's solutions. but to reiterate, Clients need addresses, People need addresses. if I create a table Address, I could relate it back to Client, and relate it to Person.
So maybe I should change the name to:
Business Person
Person will have two booleans 'isEmployee', and 'isClient', with a SSN Business will have two booleans 'isClient', and 'isVendor' with an EIN
both will have a to-many to Address and each address will have a type (i guess a business address will not be a 'love-nest').
I just never created an Entity that related back to two other Entities. So does that mean
Business <=>> Addresses Person <=>> Addresses
and because of the structure, the relations have to be optional. although an address will always be related to either a Business or a Person.
Or how about an Entity Address and a subclass PersonAddress and another subclass BusinessAddress?
Opinions?
On Sep 14, 2013, at 10:29 PM, Ramsey Gurley < email@hidden> wrote: Personally, I would look more closely at your person class. Is a client actually a person too? It sounds like it. If so, I would not have a client entity. I would simply make a person entity and assign each person one or more roles. A person might have a client role, a vendor role, and a customer role. Then you simply have a relationship between person and address.
|