On Sep 16, 2013, at 9:51 AM, Joel M. Benisch <[email protected]> wrote:
> Markus: > > As per the private email I sent you over the weekend, which you can most > certainly send to the list if you like, I believe that you are confusing > things that occur in nature (Organizations, People and Addresses) with the > "Roles" that they play in your (or any) environment and implementation. > > Have an Entity Object/Table that can contain two types of objects, People and > Organizations. A variable in the object will tell you which type "this" > object happens to be. > > Have an object/table that defines the role that any Entity is "playing" in > any given situation. You can therefore have in infinite number of Role Types. > > Than have an "EntityAggregate" object/table if you need it. This would be > used to relate multiple Entities together into any type of group you may > need. Include an AggregateType variable and you can have an infinite number > of aggregate types. This allows you to handle Departments, Offices, Spouses, > Families or any other type of combination of people you may need. It also > allows you to aggregate organizations should you need to do that, like all > Vendors of a given type, or all Clients that are serviced by a given > employee, or whatever. > The entire bit above can be summarized as "use single-table inheritance". Just FYI. Different sub-entities, even if in the same table, can have different attributes, and it is simple if the attributes are not mandatory. > Then you have an Address Object/Table. Addresses can then be associated with > any member of the Entity Table, or any number of members of the Entity Table, > and you're all set. When an employee or Vendor or Client moves, you don't > delete or change the existing (now old/obsolete) address from the table, you > add the new one and flag it as "current" if you want. This way, old data > will still display and associate to the correct old address that was valid at > the time the invoice, or purchase order, or whatever was processed. It also > allows you to use the "old" address on another Entity when some other Client > or Vendor happens to rent the same space that had previously been occupied by > the first one. > I tend to add a deletedDate attribute here. Then, adding a "and the deletedDate is null" qualifier whenever I fetch objects ensures I only see the current ones. > We work in the Insurance Industry. This approach has stood the test of time > (three decades) quite well. > For instance, a person can be a Client, and also a spouse of another Client, > and also the Parent of another Client, and therefor a member of a Family > Aggregate. That same person can be a Driver on an Auto Policy, an Insured on > various policies, an officer of a Client that is an Organization Entity, etc. > These are all Roles that this Person Entity is playing. > Wow. Why can't my insurance company do this? My insurer has an idea that my wife is primary on the account and they can't figure out how I relate there. We kept separate last names. What were we thinking. :-) > The person appears once in the Entity Table, but can be used for an unlimited > number of Roles. > Just remember, entity inheritance can be your friend, especially if done right. - ray > Hope this helps, > Joel > > On Sep 16, 2013, at 8:59 AM, Markus Ruggiero wrote: > >> >> On 15.09.2013, at 06:28, Theodore Petrosky <[email protected]> wrote: >> >>> 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? >>> >> >> >> I would model this like so: >> >> Entity "LegalEntity" with "Client" extending "LegalEntity" and "Business" >> extending "LegalEntity". Both, Client and Business share many common >> attributes like name etc, Both can have individual attributes like SSN for >> Clients and EIN for Businesses. >> Now the addresses: How to model these depends on the answer to the following >> question: Can the same address be used for different purposes? >> If no: >> Create an entity "Address" and have one attribute called "addressType" or >> some such. AddressType is one out of "home", "work", "love nest" etc. and >> model "LegalEntity" <-->> "Address" >> if yes: >> Create an entity "Address" without a type specifier. Create an intermediate >> entity like "LegalEntityAddress" with an attribute to specify the type. >> Model the following relationships: >> "LegalEntity" <-->> "LegalEntityAddress" <<-> "Address" >> >> Hope this helps. >> Have fun >> ---markus--- >> >> >>> >>> On Sep 14, 2013, at 10:29 PM, Ramsey Gurley <[email protected]> >>> 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. >>>> >>>> >>>> On Fri, Sep 13, 2013 at 9:29 PM, Theodore Petrosky <[email protected]> >>>> wrote: >>>> I need an opinion about relationships. >>>> >>>> I want to have an entity Person with a to-many to address. a Person could >>>> have many addresses (home, second home, weekend place, love nest). >>>> >>>> And I have clients. a Client needs addresses too (billing, main office, >>>> act rep, etc) >>>> >>>> how would you model this? >>>> >>>> a person entity with a to-many relationship to address >>>> a client entity with a to-many relationship to address >>>> >>>> or would you create a subclass of address and map that to the clients. >>>> >>>> is it 'bad' to have two to-many relations to an entity, (both person, and >>>> client mapped to entity address). >>>> >>>> Ted >>>>
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
