Choose between one-to-one and component in NHibernate -


i trying map classes user , profile, following:

public class user {     public long id { get; set; }     public string loginname { get; set; }     public profile profile { get; set; } }  public class profile {     //the id same user's id      public long id { get; protected set; }     public string nickname { get; set; }     public gender gender { get; set; } } 

so, can mapped both one-to-one , componenet relationship. , find people appraise component , think one-to-one bad practise, why? performance reason? designed 2 separate tables in many scenarios(asp.net2.0 membership, example).

how should choose? aspects should consider? know component means "value object" not enitity, mean further things?

ps: , confused me more opinion many-to-one should used it's one-to-one relationship in real world!

you should use neither.

one-to-one

you have user , profile in different database tables both share mutually exclusive pk: see http://jagregory.com/writings/i-think-you-mean-a-many-to-one-sir/

pretty bad design practice relational databases, it's messy , not enforce constraints relationship.

component

you can use component clean object-model messy relational database, profile , user data both stored in same database table should separated in object model (like want it, judging code). lazy loading isn't supported, cause high database traffic.

reference

imho, should use reference. it's conceptual kinda one-to-one user references profile. profiles can stored in own table, can loaded lazily (performance) , not dependent on user.

regarding confusion: read link supplied. technically, need many 1 designed database-scheme, technically possible , mapped. know it's confusing. if need map one-side, think of reference instead of one-to-one.


Comments

Popular posts from this blog

asp.net - repeatedly call AddImageUrl(url) to assemble pdf document -

java - Android recognize cell phone with keyboard or not? -

iphone - How would you achieve a LED Scrolling effect? -