Richard, thanks for being the voice of reason. I apologize for letting my tone get a mite out of hand. I apologize especially to Frans, since I know he really doesn't mean harm to anyone.
> but many many-to-many relationships are objectified. See for > example the Order - Product M:N relationship, over orderrow. This is a good point to bring up. The relationship here, in my experience, is often its own separate thing-in-itself because it often carries extra properties of its own. It's natural to attach quantity, etc. in both the database and object model. Same goes for the other examples you can provide. The thing is, an order item is an actual thing-in-itself, and not just a relationship; it has a relationship with its order and the product, together with its own data. It's a good point that you bring up, but it doesn't mean that many-to-many relationships (in and of themselves) should be objectified. Whether you consider what you call "orderrow" to be a thing-in-itself or a many-to-many with added properties, you get my drift. I think that many people would agree with me on this, although I find your point of view interesting. At least one widely-known industry tool I can point to in support of my position has nothing to do with anything object-oriented, interestingly enough. If you've ever used ERWin to do your modeling (sorry, but that's the only tool for DB design I've used besides Visio and plain old paper), you will remember that in the logical view, many-to-many relationships are reflected with simple lines between what ERWin calls entities. They show up as auto-created tables in the physical model, though. > Often people want to persist a complete object model in a total > different relational model and wonder why the O/R mapper is so darn slow > or why it is so complex. It's not complex, it's simple, you should do > what needs to be done to implement the functionality to implement, not > do what you think is required to create the most beautiful oo tree in > history just because you can :) Well, I think that there are many reasons that people write programs. I'm not completely well-versed in extreme programming principles, mostly having read what others have to say about them, but it seems to me that one point of XP is that you should get the project done as fast as possible, and not spend any extra time trying to make the program better than it needs to be. The explanation for this is that often programs are thrown away in matter of months or years anyway, wasting any effort; even a program that is enhanced later on may waste this extra work. I think that this is a good point, but there's a difference between writing a one-off departmental GUI and enterprise software, where things like speed, scalability and reliability are of utmost importance (although often neglected). So, for example, while I feel that most often the object schema will closely resemble the database schema (where the database and application are developed together), I still have never, ever objectified a pure many-to-many relationship in my code. It is very bad to create extra objects that you don't need in ANY object-oriented language, I don't care what it is. You suffer many times: the cost of creation, the extra memory overhead, extra method calls all over the place to manipulate the data, and sometimes worst of all, you must destroy the object. Not only that, but the database (even more than the object model) is often subject to modification to support better performance. That's the reason for denormalization. In fact, the same logical design is sometimes best implemented with different physical tables on different databases. I think that I can sum up your previous argument about how to construct an object schema this way: 1. Construct your database, following standard relational modeling rules (You don't mention anything about things like denormalization, what normal form you should stick to, etc. You must realize, at least, the folly of constructing an object schema to directly mirror a 5th-normal-form database. This would most likely be bad on performance from both a database and an object perspective.) 2. Construct one class for ever table The thing is, though, that it's often the case that actual software is developed with many different reflections of a database table in class form. Just think of summary data, for instance, where only a little bit of the data in an object finds its way into an object or some XML or what have you. Not only that, it's natural in some persistence scenarios for each object that links to another to only contain the key of the other. Think of how things are implemented in J2EE land. If you don't do this, you have to look up the entire data graph when just one object is requested. Still, the database foreign key of a persisted object really has nothing to do with the object model. Object-to-object links in languages like C# and Java are implemented as object pointers, and you never even see or care about the actual mechanism involved. See, I think that the problem here is that many OO people would say that it's correct to think about the application from an object-oriented perspective, and then build the database to most expediently provide storage for the application. Where they have to use an existing database, they will still construct the "correct" OO schema and map it to the database. Hence the need for tools ike OR mappers; if people wanted to mirror things exactly the mapping would be simple indeed. Another example of where relational and object-oriented ways of modeling things just can't be perfectly reconciled is in subtype relationships. In a database, I prefer to create a main table (representing the superclass or interface in the object model), then create extension tables, each with the special properties of each subtype or implementing class from the OO model. But to do things your way, I would first recognize that a subtype relationship exists, then create my extension tables, then create one class for every table, each class containing . I have a strong feeling that things like inheritance, interface implementation, polymorphism, etc. are not directly supported by relational databases. You always need to construct something like an extension table and CONSIDER it to be a subtype, etc. I think that it's often possible to construct clean, fast applications your way as well. I'm just explaining my point of view on what I think the disconnect is here. Jeff --- Frans Bouma <[EMAIL PROTECTED]> wrote: > > " A relational model in a database is not something > > cooked up over > > a dinnertable, it's the result (!) of an abstract model like > > a NIAM/ORM model. In there you define entities, like customer > > and order, and define relationships between them. These > > relationships aren't there just because some moron thinks > > they should be there, they are there because these entities > > have these relationships. This means that EACH instance of > > these entities have these relationships. " > > > > Come on, Frans. You know, at your level of experience, that > > the physical model of a database is often very different from > > the logical one. He's saying that it's sometimes the case > > that someone builds a database first and the application > > after, and that the data structures often then mirror the > > table structure. He's right! I've seen this very thing in > > practice. Think of a structure with lots of mapping tables, > > and a special object created for every one of those links, > > because some developer thought it was a good idea to create > > class AToBMap to mirror table a_b_map. Yet a mapping table > > is usually the simplest and best way, and often the only way, > > to represent a many-to-many relationship in many RDBMSes. > > but many many-to-many relationships are objectified. See for > example the Order - Product M:N relationship, over orderrow. Or > department - employee which has a 'datestarted' field. These m:n > relationships require a 3rd object. Now, when an m:n relationship is > suddenly objectified, it pops up in the open. Why is that? After all, > the m:n link table IS an entity, by definition of the relational model. > Admitted, often it is dumbed down as 'not important' and is hidden away, > but this can often lead to trouble once a table with solely FK fields in > a combined PK is suddenly equiped with a non-pk mandatory field. A lot > of code will break where you wouldn't expect it. > > Often people want to persist a complete object model in a total > different relational model and wonder why the O/R mapper is so darn slow > or why it is so complex. It's not complex, it's simple, you should do > what needs to be done to implement the functionality to implement, not > do what you think is required to create the most beautiful oo tree in > history just because you can :) > > > Not only that, but even without normalization, > > denormalization, bad design in the database (ever have to > > write an application that used an existing bad structure?), > > etc. it is often natural to implement many complicated things > > differently in database and object form. Things aren't > > always as simple as we'd like to be. > > Legacy stuff is a problem indeed. Bad designed relational > models, databases with tables without a PK but with a UC :D. If these > bad designs are included in the code, you have two times the trouble. > > I doubt however if you can make this misery any less bad for > your project when you're including a layer which allows you to create a > complete different object model with apparently no logical connection > (exxagerated) with the database model. You then run the risk the OO code > is also unmaintainable in the end because yuo need a lot of in-depth > knowledge where which data is stored, why that FK constraint is throwing > an exception when you want to write a hierarchy to the database etc., > when you want to update that code after, say, 6 months of not working on > it. :) > > FB > > =================================== > This list is hosted by DevelopMentorŪ http://www.develop.com > Some .NET courses you may be interested in: > > NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles > http://www.develop.com/courses/gaspdotnetls > > View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
