Not my fault that someone else rezzed this thread. I seem to have missed JvdL's reply back in december@JvdL said:@bjolling said:<snip>Now take his model:[snip]Done properly, this would generate 4 tables: * Person => PersonID, FirstName, LastName, PersonCategory (which is not needed) * Person_Instructor => PersonID, HireDate * Person_Student => PersonID, EnrollmentDate * Person_Administrator => PersonID,AdminDate The "PersonID" appears in all 4 tables so you can JOIN.Wrong again: this database model allows one person record to be related to an instructor as well as a student. That may be an accurate representation reality: a teaching assistent tends to be an instructor as well as a student. But is not an isa realitionship. In your OO model, instructor and student are two classes inheriting person and unless you use multiple inheritance, student and instructors are distinct objects and can therefore not be the same person. Why not? A real-life person could be represented by multiple instances of a child of the Person class. The limitations that you see have nothing to do with ORM. If you would use stored procedures or SQL queries, you would need to handle this case as well.@JvdL said:@bjolling said:This database structure might not be perfect but it is good enough for my line of business application.If I got paid everytime I heard this I would be a millionaire. No wait. I am getting paid to clean up shit like this and I am a millionaire. Please continue.I've cleaned up a lot of shit as well. I always had happy customers that welcomed me back for more projects, so I must be doing something right. So what?@JvdL said:@bjolling said:So how would you have modeled this in the DB in such a way that I would not have been able to use OO fully in my codeThere is no short answer to this question but I will give a few hints * Make a data model for the database, regardless of any line of business application * Put data constraints in the database or it will corrupt. Users don't care about our lovely applications.Our apps are just passing guests. Their data will continue to live long after our apps have been dumped. * RDB models are not about structure - they are about data. Two tables with the same types of columns are not the same. Read up on normal forms and primary key candidates: they are about data, not structure. * Don't waste your time modeling inheritance. Since DB don't give support (like polymorphism) for it, you're wasting your time * Model DB's for law & order * Make object interaction graphs and class models for your application domain. * Objects are the same if they behave the same. This has nothing to do with their data attributes. A person and a corporation may be in the same class in a legal application but datawise they have nothing in common. * Model OO for freedom & flexibility So you are a "DB centric" kind of guy and I'm a "code centric" kind of person, which explains why we have different priorities. But that doesn't mean I won't create a proper database model.You didn't answer the question by the way. None of your guidelines will prevent me from using an ORM tool to map your perfectly normalized tables to OO classes. I CAN map your tables correctly to OO parent-child hierarchies if I want to. I don't care if the DB doesn't know about this notion. Why would I? I'm using an ORM to avoid having to write all data access code myself.@JvdL said:In practice, you will have a tool for say, student registration, that is widely applicable to learning institutions, and you want to sell it world wide. You'll not find a university that doesn't already have a database and you'll be hard pressed to find two that have the exact same database model. How will you map your application model objects to all these distinct DB's with ORM? You won't. But I will be able to do that easily - although again it has nothing to do with ORM but with a well thought-out architecture.The classes I map to don't have behaviour. As long as we are in the data access layer, these objects are nothing more than data containers. So for every university in your example, I will regenerate custom data containers, e.g custom StudentData class.In the business layer however, I work with the Student class. This is my domain entity that implements the business rules. So I need to add a mapping layer to correctly map the customized StudentData class to the generic Student entity. In the past I have done this mapping with custom code, but I've also used BizTalk mapper.This allows you to generate a mapping configuration file that your code can import, so you don't even need to customize your mapping layer