Hi Frans, Ok, now we are getting somewhere. I respect your knowledge and experience in principle (that is all I can do in a forum) if you respect mine Frans. "It's very easy to babble on a forum that inheritence is great" One thing that I've learned in software developement is that any technology is good as long it is used properly. You have insinuated that I was a Purist and still have not explained me why (plus some other things). I think that this kind of insinuations in order to cloud ones observations with nothing but icons that are commonly reconed as negative should be refrained unless you prove your point with facts. "how should a 4 layer class hierarchy be constructed in DDL" What is the problem of having four tables linked with each other, and a in each table an attribute indicating the class representing each level? Eventually one can have a view joining the four tables. This is one approach there are more 2 at least that I know. "Imagine a class hierarchy: Employee<-Manager. You model this away in E/R probably with 1 table with a flattened out hierarchy, because that's the most efficient." It may not be the most efficient. "Now, your class model CHANGES: Employee<-ManagingEmployee<-Manager and Employee<-ManagingEmployee<-Executive. Happy migrating your DATA, after migrating the E/R model." I understand that this may seam to be a problem, but it is not a problem becouse it is not common practice. It may happen, but once the model is established and correct for the given problem domain, extending the systems features hardly requires this kind of changes to the model. It may, but is not common. Furthermore, this problem is also shared with E/R. Suppose that you have a E/R Model A-C. Software is deployed. After 5 months you decide that the application needs new feature. You change the model to A-B-C. Whouldn't you have to migrate data? The point is, every time you change existing object associations/inheritance (existing facts in ORM, relationships in E/R) you have to migrate data. "EXACTLY the same is present in the O/R mapper cache thread. Two people with released products on the market (Thomas and myself) elaborate why caching can be dangerous. The arguments are simply ignored, because some people think their view of reality (pun intended) is the complete view, however there is something missing" Caching can be dangerous indeed, but I'm afraid is a necessary Evil for O/R Mappers. I'm prepared to change my mind on caching thought, where can I find those papers stating why it is dangerous, but not only that but also proposing a complete alternative? I think they are a necessary Evil becouse without them database calls will much more then common ADO.NET approaches. Unless, the tools over the table function more like "DAO"/R Mappers I can't se how caching can be avoided. Nuno