I'll look into details at the <any> attribute, but it looks incompatible with enforcing a FK constraint at the DB level, which is a good sanity check
As for the role of a Company or a Contact, it's just that we need to interact with these without them being clients. Contacts and Companies are there for address book purpose mainly, and a Contact often works for a Company that is not necessarily a client. But some Contacts may be employees, or contractors etc... And Companies can represent suppliers, or other partners for instance. What surprises me is the apparent simplicity of my domain model. If I where to do a DAL manually, it'd be fairly simple and queries would be natural, yet, it looks like I'm out of the usual easily-supported scenario. Blaise On Aug 11, 4:31 pm, Diego Mijelshon <[email protected]> wrote: > 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.
