You CAN use heterogeneous relationships (see <any>). But I still believe you
are not modeling right.
What is the role of a Company or Contact in your application, besides being
a Client?
Put another way, in which relationships does it appear, that are completely
unrelated to selling stuff to them?
Now, if the *final user* of the application only considers these entities
"Clients" after making a sell, that's something to take care of in the UI
(or service layer, whatever).
Diego
On Wed, Aug 11, 2010 at 10:50, Blaise <[email protected]> wrote:
> I can't seem to explain clearly. Let me try again :)
>
> a Contact is a person like you and me. it has a firstname, a lastname,
> a date of birth etc...
> a Company is a business, with a name, employees etc...
>
>
> Then we sell stuff to Clients. So a client has number, receives
> quotes, bills etc
> But a client (in the business sense) can be a another business (a
> Company) or an individual (a Contact).
> Again, not all Companies are Clients. Same for Contacts.
>
> So Contact, Company and Clients are three completely different
> entities that should not share an inheritance hierarchy.
> But a Client must reference either a Contact or a Company
>
> Is that clearer ?
>
> The natural way of mapping that to a schema for me was to have to
> foreign keys in the table Client, one for Contact and one for Company,
> each with a unique constraint on it. But that doesn't play well with
> nHibernate.
>
>
> Thanks
>
> Blaise
>
>
>
>
>
> On Aug 11, 3:01 pm, "Frans Bouma" <[email protected]> wrote:
> > > So, I'm back with my initial problem, except I'm free to design the db
> > > schema as I see fit.
> > > But even with _no_ constraint watsoever, I can't seem to find a correct
> > way
> > > to map my classes to my DB.
> >
> > > The scenario is simple, and probably very common too (still the same
> > > scenario as my initial post) :
> > > We've got Clients. Clients can be businesses or customers.
> > > So in terms of classes, we have Client, Contact and Company.
> > > A Contact has a property Client (may be null because not all Contacts
> are
> > > clients). Same for Company.
> > > And a Client has two properties, Contact and Company, but only one of
> them
> > > is non null.
> >
> > I find it hard to follow: a client can be a business or a
> customer,
> > yet you say you have client, contact and company. Where's customer?
> >
> > Also you shouldn't think in properties, but in relationships. FK
> > side depends on PK side, and only 1 PK side. What you want is to switch
> > between PK sides for a given FK side, that's nonsense, since the FK
> side's
> > fields (for mapping, the FK fields in the table you map in the mapping
> > files) are derived from the PK fields they refer to. That's what it
> means:
> > Customer 1:n Order -> Order gets the PK field of Customer as FK field.
> You
> > seem to want to switch between PK sides, which is incorrect.
> >
> > However, I fail to see why you want this. You don't think in
> > entities and their relationships but in code and how to cram that into
> some
> > tables. That's the wrong way to look at things: try first to determine
> which
> > entities you have (I assume: Client, Company (subtype of Client) and
> > Customer (subtype of Client), and Contact) and how they relate to
> eachother,
> > THEN try to create a model from that in the DB, preferably by using T.A.
> > Halpin/Nijssen's approved system to project an abstract entity model with
> > inheritance onto a relational model, e.g. what's been used in ORM/NIAM.
> This
> > is pretty straight forward, you have to make a decision whether you want
> to
> > create 1 target (table) for an inheritance hierarchy or 1 table for each
> > entity in the inheritance hierarchy but that's about it. The main problem
> is
> > which entities there are, and how they relate to eachother, as you don't
> > seem to have that figured out yet.
> >
> > FB
> >
> >
> >
> >
> >
> > > We could model that with an abstract class Client, and two contrete
> > classes,
> > > BusinessClient that has a non null Company property and a
> CustomerClient
> > > that has a non null Contact property.
> >
> > > The natural (for me) db schema doesn't work (cf earlier post).
> > > So I'm trying to have my one-to-one mappings on the primary key, that
> is
> > if
> > > a Client is b2c, then the Client PK is the PK of the Contact, and if a
> > > Client is b2b, the Client PK is the PK of the Customer.
> >
> > > But that doesn't really work either because nHibernate Id generator
> > > "foreign" only accepts a single entity has a foreign key source.
> >
> > > And Creating a class hierarchy doesn't work eigher because the
> generator
> > > must apparently be set at the root class.
> >
> > > So I welcome any advice, because I'm somewhat stumped: my domain model
> is
> > > simple, yet I can't seem to find a good and simple way to map it to a
> > > storage model.
> >
> > > Thanks
> >
> > > Blaise
> >
> > > On Jul 26, 2:49 pm, Fabio Maulo <[email protected]> wrote:
> > > > aaahhh you never said you are using a Eliot Ness DB.
> >
> > > > I'll check what happen with your Eliot Ness.
> >
> > > --
> > > You received this message because you are subscribed to the Google
> Groups
> > > "nhusers" group.
> > > To post to this group, send email to [email protected].
> > > To unsubscribe from this group, send email to
> > > [email protected]<nhusers%[email protected]>
> .
> > > For more options, visit this group at
> > >http://groups.google.com/group/nhusers?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "nhusers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<nhusers%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/nhusers?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en.