Java Community News - Gavin King: In Defence of the RDBMS

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Java Community News
Gavin King: In Defence of the RDBMS

195 replies on 14 pages. Most recent reply: Jun 20, 2007 6:11 AM by James Watson

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 195 replies on 14 pages [ « | 1 ... 3 4 5 6 7 8 9 10 11 ... 14 | » ]

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Gavin King: In Defence of the RDBMS

Posted: May 31, 2007 12:08 PM

Reply

Advertisement

> > For example, if you created classes before XML was
> widely
> > used, you need to modify all of those classes to enable
> > the transformation of the class's data to XML.
>
> In theory, you shouldn't. I used to think Alan Holub was
> a nut and then one day I got it. I'd probably explain it
> poorly so I won't try but I read the getters and setters
> are evil article a bunch of times and it finally clicked.
> If you haven't read it, it's worth a read even if you
> u ultimately disagree with it.

Yes, I've read the article. In general I find that articles that say such and such practice is "evil" are almost always wrong and this one didn't disappoint me.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Gavin King: In Defence of the RDBMS

Posted: May 31, 2007 12:23 PM

Reply

> For example, if you created classes before XML was widely
> used, you need to modify all of those classes to enable
> the transformation of the class's data to XML.

No matter what, somebody has to write code to transform the class's data to XML. The only question is where it goes and how you call it.

SOOP says you implement however and wherever you see fit, (though probably largely within the class, some superclass, or some closely associated helper class) then call

myFoo.toXML();

LOOP (typically) says you create an XMLifier class for each class you want to convert to XML, then create a Factory for them, edit some XML configuration files, then call something like

ApplicationContext.getInstance().getXMLifierFactory().getXMLifier(myFoo.g etClass().getName()).toXML(myFoo);

We can legitimately disagree over which is best, that depends, but you can't argue for this case that SOOP is "more work". For example, myFoo.toXML() could simply call that huge ApplicationContext... line.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Gavin King: In Defence of the RDBMS

Posted: May 31, 2007 12:51 PM

Reply

> > For example, if you created classes before XML was
> widely
> > used, you need to modify all of those classes to enable
> > the transformation of the class's data to XML.
>
> No matter what, somebody has to write code to transform
> the class's data to XML. The only question is where it
> goes and how you call it.
>
> SOOP says you implement however and wherever you see fit,
> (though probably largely within the class, some
> superclass, or some closely associated helper class) then
> call
>
> myFoo.toXML();
>
>
> LOOP (typically) says you create an XMLifier class for
> each class you want to convert to XML, then create a
> Factory for them, edit some XML configuration files, then
> call something like
>
> ApplicationContext.getInstance().getXMLifierFactory().getXM
> Lifier(myFoo.getClass().getName()).toXML(myFoo);
>
>
>
> We can legitimately disagree over which is best, that
> depends, but you can't argue for this case that SOOP is
> "more work". For example, myFoo.toXML() could simply call
> that huge ApplicationContext... line.

XML might have been an bad example (although you certainly made it look more complicated than it could be), but the broader point is that if an object can make its data accessible, another part of the application could use the data in a way that was unanticipated by the original class designer. In some cases a single method can correctly handle data from any class so the choice is between modifying all the classes to add the functionality, or just add the functionality to the object that consumes the data.

Of course you're assuming that you have access to the orginal source code in question which may or may not be the case. Another of Holub's rules is that "extends is evil" so you can't subclass even if your language would allow you do so without having the source.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Gavin King: In Defence of the RDBMS

Posted: May 31, 2007 1:14 PM

Reply

> SOOP says you implement however and wherever you see fit,
> (though probably largely within the class, some
> superclass, or some closely associated helper class) then
> call
>
> myFoo.toXML();

I would actually prefer the Builder (GoF) approach if you wish to address the concern Jeff has.

So you would call:

FooBuilder xmlWriter = new FooXMLBuilder();
 
myFoo.out(xmlWriter);

Then you can create as many builders as you want and unless something changes about how Foo for some other reason, you don't need to modify Foo to add new ways to display Foo.

This is a lot more work that exposing the internal structure of Foo and I can't imagine that it would make sense to do this on every class but this is the kind of thing Alan Holub is talking about in the getters and setters are evil article. Or at least that's what I've convinced myself he means.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Gavin King: In Defence of the RDBMS

Posted: May 31, 2007 1:45 PM

Reply

> broader point is that if an object can make its data
> accessible, another part of the application could use the
> data in a way that was unanticipated by the original
> class designer.

This may or may not be good. e.g. invariants, synchronization, etc. This is another reason, not mentioned by Holub, why Setters are not-great.

Also, in my experience, objects that make their data available tend to be lazy and not only allow other classes to do things, they require or, at the minimum, entice others to do things. See references to Anemic Domain Models. The worst example I saw was a class with a lot of getters and setters, then a totally separate class to validate all those values.

Anyway, we have wandered very far away from RDBMSs.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Gavin King: In Defence of the RDBMS

Posted: May 31, 2007 2:34 PM

Reply

> This may or may not be good. e.g. invariants,
> synchronization, etc. This is another reason, not
> mentioned by Holub, why Setters are not-great.
>

When you get into synchronization issues, the "class should do everything itself" theory has a lot of traps as well.

> Also, in my experience, objects that make their data
> available tend to be lazy and not only allow other
> classes to do things, they require or, at the
> minimum, entice others to do things. See
> references to Anemic Domain Models. The worst example I
> saw was a class with a lot of getters and setters, then a
> totally separate class to validate all those values.
>

Well, there's no reason why there can't be an appropriate mix unless those implementing a class only believe in extremes.

Dead hand rules just can't compete with engineering judgment applied with the knowledge of the problem being solved.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Gavin King: In Defence of the RDBMS

Posted: May 31, 2007 3:59 PM

Reply

> Or at least that's what I've
> convinced myself he means.

OK, I did this again. I don't know why I keep projecting this on him. He doesn't argue this. I don't agree with him at all. Actually, he says some things in that article that are just dumb, IMO.

The builder pattern does allow you to not have getters and setters and not embed concrete display of an Object (for example) in it's class.

Sorry for any confusion.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Gavin King: In Defence of the RDBMS

Posted: May 31, 2007 4:15 PM

Reply

Builder pattern is a nice improvement.

BTW, just noticed that the current Java Developers Journal compares Hibernate, db40, and Cache.

http://java.sys-con.com/read/377037.htm

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Gavin King: In Defence of the RDBMS

Posted: Jun 1, 2007 12:02 AM

Reply

> Also, in my experience, objects that make their data
> available tend to be lazy and not only allow other
> classes to do things, they require or, at the
> minimum, entice others to do things. See
> references to Anemic Domain Models. The worst example I
> saw was a class with a lot of getters and setters, then a
> totally separate class to validate all those values.

Anemic Domain Models seem to correspond with the dual anti pattern of the all responsible God Class.

> Anyway, we have wandered very far away from RDBMSs.

Sure, but while the discussion slowly fades away it comes closer to the point of admitting that properly designed OOP programs require a better data infrastructure. Dependency injection ( or bijection as in JBoss Seam ) is on the right track. Data-exchange between objects become more declarative. But then OOP might become declarative programming in the large?

I have to stop here because an SQL command has just entered my brain...

Ivan Lazarte

Posts: 91
Nickname: ilazarte
Registered: Mar, 2006

Re: Gavin King: In Defence of the RDBMS

Posted: Jun 1, 2007 12:24 AM

Reply

Is it only the "anemic" domain model because Martin Fowler said so? Validations outside of the value object become really easy to use and re-use or not if needed. Amazingly enough, there are times when you want a different set of validations for the same set of data. Businesses are arbitrary, who knew!

Tony Marston

Posts: 37
Nickname: tony32
Registered: May, 2007

Re: Gavin King: In Defence of the RDBMS

Posted: Jun 1, 2007 2:25 AM

Reply

> If I dig out a hole for a swimming pool with a
> teaspoon, I may create a hole with exact dimensions
> required. In that context, the hole is not wrong. But
> I'd still be an idiot. It was the wrong choice,
> regardless of whether the outcome was correct.

You can dig a hole with a teaspoon, a shovel, or a mechanical digger. You may use one or more diggers (people or machines). The choices depend on your budget, your timescale, or other constraints. What happens if you cannot get you mechanical digger to the site where the hole needs to be?

Regardless of how you actally do it, if the object of the exersize is to dig a hole of certain dimensions, to budget and within timescale, and you actually achieve that, then you are not wrong. Your methods may not have been the most efficient, but that is irrelevant. At the end of the day it is the result that counts, not the elegance of your implementation.

> I agree that OOP can provide maintenance benefits (when
> done properly) but it can also provide benefits up-front.
> It's often much easier to create correct code with OO
> O off-the-bat, in my experience.

Define "properly". There is no single, universally accepted description of what "proper/pure/real" OO really is.

> Since you are not being harsh, I'll say what I believe we
> are both thinking. If someone thinks that any code that
> uses Objects and classes is OO, then that person probably
> doesn't really understand OO.

The definition of Object Oriented Programming is simple and straightforward - it is programming which is oriented around objects, thus taking advantage of Encapsulation, Polymorphism, and Inheritance to increase code reuse and decrease code maintenance. Therefore, if I write software that uses classes, objects, encapsulation, inheritance and polymorphism then that *IS* OOP whether you like it or not. The style may not be to your liking but that is irrelevant.

My personal style is to use one class per database table, and to avoid OR mappers like the plague. I also use one DAO per DBMS, not one per table, and I use a data dictionary instead of Activerecord. So, if that is different from *your* personal style, would you consider it to be *wrong*?

Tony Marston

Posts: 37
Nickname: tony32
Registered: May, 2007

Re: Gavin King: In Defence of the RDBMS

Posted: Jun 1, 2007 3:24 AM

Reply

> If I dig out a hole for a swimming pool with a
> teaspoon, I may create a hole with exact dimensions
> required. In that context, the hole is not wrong. But
> I'd still be an idiot. It was the wrong choice,
> regardless of whether the outcome was correct.

If it is stupid to dig a hole with a teaspoon, then would you agree that it is also stupid to write an application against a badly designed, unnormalised database?

If the database has been properly normalised, then would you not also agree that it is stupid to have an application structure which is totally different from the database structure?

If it is in fact the best idea to have a properly normalised database, and to have an application structure which mirrors the database structure, then would you not also agree that in those circumstances it is stupid to employ an ORM? After all, the sole purpose of an ORM is to deal with the differences between the two structures? If the two strucures are the same, then an ORM is redudant and superfluous.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Gavin King: In Defence of the RDBMS

Posted: Jun 1, 2007 6:14 AM

Reply

> > If I dig out a hole for a swimming pool with a
> > teaspoon, I may create a hole with exact dimensions
> > required. In that context, the hole is not wrong. But
> > I'd still be an idiot. It was the wrong choice,
> > regardless of whether the outcome was correct.
>
> You can dig a hole with a teaspoon, a shovel, or a
> mechanical digger. You may use one or more diggers (people
> or machines). The choices depend on your budget, your
> timescale, or other constraints. What happens if you
> cannot get you mechanical digger to the site where the
> hole needs to be?

You use a shovel, not a spoon.

> Regardless of how you actally do it, if the object of the
> exersize is to dig a hole of certain dimensions, to budget
> and within timescale, and you actually achieve that, then
> you are not wrong. Your methods may not have been the most
> efficient, but that is irrelevant. At the end of the day
> it is the result that counts, not the elegance of your
> implementation.

Tell that to the person paying for the labor.

> > I agree that OOP can provide maintenance benefits (when
> > done properly) but it can also provide benefits
> up-front.
> > It's often much easier to create correct code with OO
> > O off-the-bat, in my experience.
>
> Define "properly". There is no single, universally
> accepted description of what "proper/pure/real" OO really
> is.

I never said there was. But a lot of things are very nearly universally understood to not be OO, even by those who disagree about what OO is.

> > Since you are not being harsh, I'll say what I believe
> we
> > are both thinking. If someone thinks that any code
> that
> > uses Objects and classes is OO, then that person
> probably
> > doesn't really understand OO.
>
> The definition of Object Oriented Programming is simple
> and straightforward - it is programming which is oriented
> around objects, thus taking advantage of Encapsulation,
> Polymorphism, and Inheritance to increase code reuse and
> decrease code maintenance. Therefore, if I write software
> that uses classes, objects, encapsulation, inheritance and
> polymorphism then that *IS* OOP whether you like it or
> not. The style may not be to your liking but that is
> irrelevant.

You did not say that before. You said code that uses Objects and classes is inherently OO. This is not true.

> My personal style is to use one class per database table,
> and to avoid OR mappers like the plague. I also use one
> DAO per DBMS, not one per table, and I use a data
> dictionary instead of Activerecord. So, if that is
> different from *your* personal style, would you consider
> it to be *wrong*?

No. I've seen the one-table->one class approach cause a project to nearly fail but I won't say it's not OO.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Gavin King: In Defence of the RDBMS

Posted: Jun 1, 2007 6:48 AM

Reply

> > If I dig out a hole for a swimming pool with a
> > teaspoon, I may create a hole with exact dimensions
> > required. In that context, the hole is not wrong. But
> > I'd still be an idiot. It was the wrong choice,
> > regardless of whether the outcome was correct.
>
> If it is stupid to dig a hole with a teaspoon, then would
> you agree that it is also stupid to write an application
> against a badly designed, unnormalised database?

No. That would be analogous to digging a swimming pool in rocky soil. It would be nice to not have to deal with the rocks but no amount of wishful thinking is going to make them go away on their own. You could tell the owners of the property to move to a rock-free area and then you'll dig but that's absurd.

You have two ways to deal with the issue. Fix the DB, which is often the optimal choice or work with what is there. Often it's the case that the latter is the only option other than quitting. For example, I've often had to query databases that are not under the control of my organization. I have no power to normalize the database. But the need for the application still exists. In other cases, it's not my choice as to what the database looks like. I could be a big baby and throw a tantrum until I get my way but that's not going to get me far with others and the reality is that it's not that big of a deal. It's just another problem with a perfectly workable solution.

> If the database has been properly normalised, then would
> you not also agree that it is stupid to have an
> application structure which is totally different from the
> database structure?

Maybe, maybe not. I don't work with databases that are just an extension of my code. The databases I work with are for storing data. A data warehouse, for example has a very different focus than just persisting an application's data. It's gathering a lot of data and is geared towards reporting and/or analysis. It may be perfectly modeled for those purposes and not really well suited for my application's needs.

I'm not really of the mind that there's one true view of the data. I don't waste a lot of time trying to create a copy of the database in my application. I generally try to design the code such that it is agnostic about where the data comes from and goes to. But I haven't been writing read,update,insert GUIs for a number of years.

I think your approach works fine if the database is designed with an OO design in mind. Otherwise you are basically letting the database impose a design on your code. I haven't really had the option to design the database that often.

The other thing about this is that if you feel the database and the class design should be equivalent, why not just use an OODBMS? What are you getting out of the database?

> If it is in fact the best idea to have a properly
> normalised database, and to have an application structure
> which mirrors the database structure, then would you not
> also agree that in those circumstances it is stupid to
> employ an ORM? After all, the sole purpose of an ORM is to
> deal with the differences between the two structures? If
> the two strucures are the same, then an ORM is redudant
> and superfluous.

I don't really love ORM. I think it's hyped-up and oversold. Gavin King is a king of specious arguments and I've seen him go after people on Hibernate forums just because they don't understand his grand design and are asking why Hibernate can't do X. That leaves a bad taste in my mouth

Regardless, I think it make sense in some cases. Actually if your database tables and classes match up, it works best, in my experience. It does all the work of queries and updates and caching etc. If they don't match up, the mapping becomes more painful than writing custom SQL, IMO.

Ravi Venkataraman

Posts: 80
Nickname: raviv
Registered: Sep, 2004

Re: Gavin King: In Defence of the RDBMS

Posted: Jun 1, 2007 7:09 AM

Reply

Tony,

>
> My personal style is to use one class per database table,
> and to avoid OR mappers like the plague. I also use one
> DAO per DBMS, not one per table, and I use a data
> dictionary instead of Activerecord. So, if that is
> different from *your* personal style, would you consider
> it to be *wrong*?

I like your strong comments, especially the part which says that there is no clear definition of what constitutes OOP itself, let alone good OOP. Alan Kay, the originator of the OOP idea, feels that Java and C++ are not what he meant by OOP. I am sure this is news to most of the curly braces crowd (C, C++, Java, C#, etc.) Smalltalk OOP focusses on message passing, and Smalltalk was Alan Kay's creation.

I also like the idea of one DAO per database, which is how I, too, implement it. The mainstream implementation of one DAO class for each "Value Object" class is mystifying, and the blind acceptance of this unnecessary complexity is totally beyond my understanding.

I have never understood the need for OR mappers and have built robust applications using one DAO and no ORM tools. My code ends up simpler, yet more flexible. Given a free hand I would never use any ORM mapper, as they only lead to code bloat and obfuscation. Here, I believe that we are in a very small minority.

Flat View: This topic has 195 replies on 14 pages [ « | 3 4 5 6 7 8 9 10 11 | » ]

Previous Topic

Next Topic

Sponsored Links

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use