You can use the join element to map properties which are in another table.
You could have more or less classes as tables. Usually, you have more classes then tables. This is because of performance optimization. Classes could be as small as needed to make them reusable, and you will have classes containing code, but hardly any persistent state. Having a table for each of these small classes would result in many small and meaningless tables in the database, resulting in lots of joins which could be avoided. As a general design guideline: make a fine grained class model using common OO patterns and make your code reusable. Make a coarse grained database design to speed it up (of course considering normalization, but I don't have to tell you how to model the database if you already have one). On 7 Aug., 08:17, Sachin <[email protected]> wrote: > If I have 2 tables in my database which are joined with primary key of > a table, then can we have a single entity containing properties of > both table A & B. > > we are confused if we need to have as many classes in my code as we > have tables or is there any work around for it. > > My understanding says that we can specify references to other tables > and we can have them as properties which we can fill using eager > loading so they would be available to us when we would Get data for > that entity using NH. > > Thanks --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
