Re: structure opinions

Subject: Re: structure opinions
From: Markus Ruggiero <email@hidden>
Date: Mon, 16 Sep 2013 16:59:30 +0200

On 15.09.2013, at 06:28, Theodore Petrosky <email@hidden> 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@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.

On Fri, Sep 13, 2013 at 9:29 PM, Theodore Petrosky <email@hidden> 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@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

Markus Ruggiero
email@hidden
Check out the new book about Project Wonder and WebObjects on http://learningthewonders.com/

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

Follow-Ups:
- Re: structure opinions
  - From: "Joel M. Benisch" <email@hidden>

References:
	>structure opinions (From: Theodore Petrosky <email@hidden>)
	>Re: structure opinions (From: Theodore Petrosky <email@hidden>)

Prev by Date: Re: JRebel 5.3.2
Next by Date: Re: structure opinions
Previous by thread: Re: structure opinions
Next by thread: Re: structure opinions
Index(es):
- Date
- Thread