Many To Many Discussion

ManyToManyDiscussion

This challenge proves my point from DbasGoneBad. I'm not in competition with the RDBMS crowd. Long live the RDBMS!!! I have no wish or desire to see it not used where appropriate. However, what I see happening is somebody from the object-oriented crowd says, "Gee, an OODBMS would sure help me here," and someone from the relational crowd jumps in and trys to prove that relational is showhow better. This is an enormous waste of time. You make the assumption that there are, a priori, no solutions to these problems in the OODBMS space and I know that's simply not true. While there aren't as many OODBMS products on the market as there are relational, those that exist today are truly the best of the best. GemStone/S is a prime example and is in use today for very large installations world wide.

I restate my position: OODBMS products are not meant as a replacement for RDBMS products. They are orthogonal and complementary. I do not see having separate views of a system's data as breaking OnceAndOnlyOnce no more than I see have separate views of a table as doing so. OnceAndOnlyOnce is an ideal and not a pattern or rule to be blindly applied. Further, I contend that an object instance, with its intrinsic state and behavior, and a set of tables that may represent data derived therefrom are not the same thing, even if one begets the other. Therefore, OnceAndOnlyOnce does not apply. -- JeffPanici

I think we would have to explore an example. I suggest something based on CampusExample -- AnonymousDonor

As for the "long live RDBMS" attitude, that's cool. I would deploy an ODBMS tomorrow if I knew that it supports relational algebra out of the box. I believe Mattisse does that, so it's on my watch list for future projects. As far as I have read (admittedly older) GemStone PDF documentation about how to program in GemStone and all the tricks and trips, I could only have concluded that they suffer from ObjectRelationalPsychologicalMismatch -- they do a fine job at it, nevertheless. That would be fine with me (I am "OO" programmer/designer/architect/whatever myself ) provided that I can be shown that relational algebra can be effectively replaced by that OO voodoo. But as long as I can realize a simple information model in under 60 seconds and have tons of functionality out of the box, while OO die hards fool around with all kinds of excuses in lieu of simple code , I hardly have any sympathy for their position. And if on top of that they whine that their perspective doesn't get wider acceptance and whine about DbasGoneBad, I can only say that technically they truly deserve it.

The future of data management is not and cannot be OODBMS acceptance by decree, prozelitizing, hand waving or whatever, the same way I can bet right now that native XML databases will be the next big fiasco. The future will be of a database that will support at least relational algebra/calculus (or an elegant and equally powerful) and will have an advanced type system so that it will put together the advantages of both worlds. But I won't buy it for a second that going back to chasing pointers has any decent future. I will tell you as much, I don't know if relational is better than an unspecified target, but I'll tell you for sure: relational is in the general case way better than chasing pointers. -- CostinCozianu

[fixed objection to disqualifications... query code may be ignored if it is common knowledge (calling a method, invoking a sql query). If you're writing a fancy api to hide stuff, you'd better show us how it works]

SQL is a fancy API to hide stuff. Are you going to show us how it works?

* We're talking about amount of setup / query code, not behind the scenes code to run the show. SQL does this in 4 lines, despite tens of thousands of supporting lines of code. A java version with 50 lines also has support from the VM.

If all we need to show is set up code (query code not show in SQL example), here's the Java solution:

PrincipleTable users = new PrincipleTable();
PrincipleTable groups = new PrincipleTable();
RelationTable userGroups = new RelationTable(users, groups);

The rest is done behind the scenes.

Think about what the challenge is asking for. Once the classes have been written this is all the user of those classes has to do to create the tables. That's all that is shown in the SQL example at the top of the page.

But we know how to make arbitrary queries of an SQL schema. How do you query for (say) all users which have the same name as a group that contains them? SQL has a standard form to deal with this. Typical java solutions involve coding the queries on a case by case basis... not really ideal. Java Solution 2 attempts to allow arbitrary queries; because it's not a normal form, the manner in which we query that form has been included as well. As the guy who reworked the challenge, I apologize for loosing this detail. Of course, I'm trying to approach this from a devil's advocate point of view, perhaps CostinCozianu could help me out (after all, it's his challenge). -- WilliamUnderwood (cwillu)

Show me the SQL for that query and I'll show you the Java.

''I've already seen the java. I've written the java (including an implementation). I don't know sql well enough to be fair to the relational people. Arg! :)' -- cwillu'

The Java can be much less verbose than the WilliamUnderwood solution if all we show is how it is used.

That would be fair enough. May I ask you where do you get the underlying relational classes from ? Let me see those, so I would judge the quality of your solution. Isn't the fact that those classes are absent from the standard libraries, open source portofolio, or even so called advanced books on OO patterns, anti-patterns and refactoring, kind of telling ? --SomebodyElse?

I write the underlying relational classes. You can see them if and when I actually write them. The challenge was to show the "setup code", not the implementation. I think classes like that are "absent" because Java developers usually use RDBs for that sort of thing.

Then your entry to the challenge will be valid when you'll have written those classes. I might get ahead of you, my work schedule permitting :) And by the way, Java and OO developers usually implement ad-hoc pointer chasing solutions over and over again for managing many to many relationships, especially for non persistent objects, it's also what you read in most "advanced" books on OO design, and it has to do more with ObjectRelationalPsychologicalMismatch than with good design principles (OO or otherwise).

My solution is already valid. The challenge was not to show the implementation but the setup. My Java code shows the same setup as the SQL code: the creation of three tables. The details of those tables are hidden in the classes, but that's one of the benefits of OO programming.

With the minor caveat that your solution doesn't work today :) Did I mention that I asked for something that works ?

[Except that I have a solution which works today, and I believe he's claiming the same for his api... but that's beside the point. -- cwillu]

The SQL doesn't work without implementation. All you showed was a few declarations, so that's all I showed. Why hold Java to a different standard?

Advanced books on OO design tend to focus on OO design and ignore common real life solutions. It wouldn't make much sense to put lessons on how to use SQL in a book on advanced OO design. Remember, someone has to implement those RDBMSs. They often used advanced OO design to do so.

I assume "pointer chasing" is a pejorative term for reference passing?

It means all that annoying code when you want to destroy an object, for example, and have references to it in tons of other places so you chase for them to remove references to your object. Also the kind of code where you iterate over collection of pointers, reference and iterate over other collection of pointers, and so on, so forth. Basically managing what OO calls "object relationship" on a case by case basis, and is realized typically by pointers and collection of pointers, when the right solution is to refactor all that ad-hockery into a generic mechanism.

Strange, I never chase pointers in Java. I use objects when I need them and let the garbage collector deal with the ones I no longer use.

Upon reflection upon supplied solutions, I find it necessary to disagree with the statement that oodbs are orthogonal to rdbs. If it's a database, it better be able to store something, be it tables of strings or objects or whatever. It had better be able to share this data, and had better be able to query it arbitrarily. If an oodbs can do this, then it is equivilant to an rdbs in abilities and varies only in the datatypes that it stores. I need to read up on relation calculus/algebra, but I believe I'm pretty much in complete agreement with Costin above... -- WilliamUnderwood

ManyToManyChallenge | ManyToManySolutions | ManyToManyDiscussion