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 ... 2 3 4 5 6 7 8 9 10 ... 14 | » ]

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Terminology?

Posted: May 30, 2007 3:42 PM

> What's depressing about this quote is that Chamberlin
> defined (mostly he, anyway) SQL, which paid lip service to
> the Relational Model at the time he did it. He's also
> responsible (mostly he, anyway) for XQuery. For those who
> don't get it, XQuery is a re-creation of those five page
> navigational programs. And the network model (CODASYL)
> was better adapted to dealing with multiple relationsips
> than the IMS/hierarchical method. I guess his conversion
> was faux.

The thing is that we have a tool (which will remain nameless because I hate it) that uses an RDBMS as it's native persistence mechanism but recently added the ability to export the same stuff to XML.

I wanted to run a query to find some particular info and I was offered several pages of SQL as a starting point. I looked at the XML file and got exactly what I needed in a few lines of XPath. The SQL was dog slow. The XPath was instantaneous.

I completely agree that a lot of data doesn't belong in hierarchical data structures but somethings do. I think you are overplaying your hand here.

Frank Wilhoit

Posts: 21
Nickname: wilhoit
Registered: Oct, 2003

Re: Terminology?

Posted: May 30, 2007 5:34 PM

I decline the reproaches of the relational fanatics, inasmuch as I explicitly stated the indisputable fact that the relational model is optimal for persistent data. But it is useless for other purposes.

You can't normalize objects--which doesn't detract from objects. You can't normalize messages--which doesn't detract from messages.

Persistent data is completely different from data in memory is completely different from data in flight. Rather than insist upon the supremacy of one or another of these three, leaving the other two as an exercise for the student, we ought to face up to the fact that each requires its own intrinsically different handling and focus on understanding how to transform among them when needed.

Tony Marston

Posts: 37
Nickname: tony32
Registered: May, 2007

Re: Gavin King: In Defence of the RDBMS

Posted: May 31, 2007 3:07 AM

> > > I'm just wondering how "Object-like" your
> > > table-derived objects actually are.
> > > This is where I have a lot of concerns about your
> > > approach.
> >
> > They are VERY "object-like" insofar as they are classes
> > which need to be instantiated into objects at runtime.
> > They also make extensive use of encapsulation,
> > inheritance and polymorphism which are the only
> > requirements in OO programming.
>
>
> We really need to better define the various styles /
> implementations of OOP. Cause "it's a class, therefore
> it's OOP" doesn't really cut it for me.

The idea that there is a right and a wrong way to do OOP is totally bogus. If I write programs using classes and objects then that *IS* object oriented programming whether you like it or not. The fact that one person's style of OOP is different from another person's style does not make one right and the other wrong. They are merely different. If something works then it cannot be wrong, just as something which does not work cannot be right.

To me the wrong way to do OOP is to use as many design patterns as possible just because they are supposed to be cool. I have seen too many cases where design patterns have been used inappropriately, which results in code bloat, inneficient and difficult-to-maintain software. The ORM is one such pattern.

If the structure of your database changes then, whether you like it or not, you have to make corresponding changes to your software. I prefer to make those changes in each table's class rather than introduce the complexity and overhead of an ORM.

Tony Marston

Posts: 37
Nickname: tony32
Registered: May, 2007

Re: Gavin King: In Defence of the RDBMS

Posted: May 31, 2007 3:14 AM

> > > > This is why a lot of OO programmers cry out for an
> > > > OO database, simply to cover up their mistakes.
> > > > They want something into which they can drop their
> > > > badly designed objects instead of having to map to
> > > > a properly normalised structure.
> > >
> > > That's not true. You have to normalize the objects
> > > just like you normalize the database. Normalization
> > > is not a function of database implementation, but a
> > > fundamental property of information organization.
> >
> > Then how come the structure of these "normalised"
> > objects differs so much from the structure of the
> > normalised database? If the two structures were the
> > same then there would be absolutely no need for OR
> > mappers to deal with the differences.
>
> It does not differ at all, at least in my designs.

In that case you have no need for an ORM to deal with the differences between the two structures for the simple reason that there are no differences. That proves my point.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Gavin King: In Defence of the RDBMS

Posted: May 31, 2007 3:36 AM

> The hard part is modifying everything that depends on the
> schema. In the case of what I was responding to, the
> poster stated that code would be directly generated from
> the schema. Normalizing the schema would then change all
> these classes in non-trivial ways. I'm waiting for
> someone to explain to me how all the dependencies on those
> classes will be rectified.

That's why I prefer db4o: the code IS the schema!

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Gavin King: In Defence of the RDBMS

Posted: May 31, 2007 3:38 AM

> > That's because it's almost apples and oranges: OO is
> about
> > organizing code, DBs are about organizing data. But
> > objects will contain data at some point, so these
> objects
> > have to be organized like databases.
>
> I do think you missed a bit the point here. An object
> unifies code and data. Data is treated as internal state
> of the object, as an object attribute / property and shall
> be accessed by the object only. Relational programming
> intentionally separates both and provides a
> framework/infrastructure for dealing with pure data,
> something OO lacks by principle [1]. In your example you
> have shown lots of pure data classes. These are
> tables in OO clothes. Of course languages like Ruby,
> Python, Lisp etc. don't care much about about the
> boundaries of paradigms. They do even look at themselves
> as data. Organizational principles are adapted to the
> particular task.

Not a problem. You can put any number of methods in the classes Customer, Product and Purchase.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Gavin King: In Defence of the RDBMS

Posted: May 31, 2007 3:43 AM

> I have a question for the OO folks. The need to
> denormalize tables in order to speed queries does and can
> occur when using an RDBMS. You may have many terabytes
> worth of data and some very complex search requirements
> across many tables and you find that your queries are
> still slow so you have the option of denormalizing your
> tables. How would you accomplish this using an OO
> database/language?

Objects can contain any number of pointers to other objects. It is not uncommon to link objects in a sometimes cyclic graph for efficiency. DB4O handles that transparently.

>
> I also have a question for the RDBMS folks? How quickly
> could you produce a small application, install it, etc.
> with no DBA involved?

10 times faster, at least.

>
> Please don't answer, my point is as follows:
>
> I think one of the key underlying problems throughout the
> discussions here is that each author is concerned about
> their own context which has a high liklihood of
> differering greatly from that of the next author. Does
> the application need to scale? Is it a fairly simple
> application? Will complex and currently unknown searches
> against the data need to be performed in the future? Will
> the application need to change drastically and quickly due
> to the business you are supporting? The tools we choose
> should be based upon the context of the given problem.
>
> "there is no silver bullet" - Fred Brooks

Well, you are right, up to a degree. But there is common ground between different contexts, and sometimes this ground is 99% common (that's why we are able to reuse software).

Frank Wilhoit

Posts: 21
Nickname: wilhoit
Registered: Oct, 2003

Re: Gavin King: In Defence of the RDBMS

Posted: May 31, 2007 6:04 AM

The rationale for OOP is complexity management. If you're not using it in such a way as to organize and manage the complexity of your code, then you are using the wrong tool for the wrong purpose and wasting huge amounts of your time and effort and those of anyone who subsequently has to read or maintain your code. Some people drive nails with soup cans and use screwdrivers for chisels. Please note very, very carefully that I did not use the word that begins with "wro..."

Frank Wilhoit

Posts: 21
Nickname: wilhoit
Registered: Oct, 2003

Re: Gavin King: In Defence of the RDBMS

Posted: May 31, 2007 6:05 AM

Hm. Actually I did. How'd that happen?

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Gavin King: In Defence of the RDBMS

Posted: May 31, 2007 7:07 AM

> > We really need to better define the various styles /
> > implementations of OOP.

> The idea that there is a right and a wrong
> way to do OOP is totally bogus.

O.K., lets be PC - no harsh judgments. Would you agree that there are better and worse ways to do OOP? If not, why are you arguing on this list? :-)

> If I write programs using
> classes and objects then that *IS* object oriented
> programming whether you like it or not.

Many would disagree with you. For example, read the Naked Objects site for their view that the original design goals of OOP have been lost, and, for many, the term has lost its original meaning. Which you just proved. And is why I started tossing around the terms "Strong OOP" vs. "Light OOP".

If you write Class1 that is all public static variables, and Class2 that is all public static methods that work on Class1, that is not OOP. That is FORTRAN where Class1 is a COMMON block.

> If something works then it cannot be wrong

Tell that to my wife. :-)

Code that works but is extremely difficult to maintain or enhance is wrong. The goal (sometimes unrealized) of "Strong OOP" is easier maintenance.

> To me the wrong way to do OOP is to use as many
> design patterns as possible just because they are supposed
> to be cool.

Here, I agree with you.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Gavin King: In Defence of the RDBMS

Posted: May 31, 2007 8:52 AM

> > > We really need to better define the various styles /
> > > implementations of OOP.
>
> > The idea that there is a right and a
> wrong
> > way to do OOP is totally bogus.
>
> O.K., lets be PC - no harsh judgments. Would you agree
> that there are better and worse ways to do
> OOP? If not, why are you arguing on this list? :-)

You are being too generous. The argument that all approaches are equally correct and effective is untenable in any context.

The fact of the matter is that just because you use an OO language doesn't mean you are creating OO design. A pair of Nikes won't make you a professional basketball player either.

A developer can create OO designs in procedural languages. Likewise, one can create procedural designs in OO languages.

> > If something works then it cannot be wrong
>
> Tell that to my wife. :-)
>
> Code that works but is extremely difficult to maintain or
> enhance is wrong. The goal (sometimes unrealized) of
> "Strong OOP" is easier maintenance.

To add: 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.

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 off-the-bat, in my experience.

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.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Gavin King: In Defence of the RDBMS

Posted: May 31, 2007 10:41 AM

James - yes, I was in a good mood this morning.

Maybe we should write a "Good Cop / Bad Cop" OOP article? :-)

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Gavin King: In Defence of the RDBMS

Posted: May 31, 2007 11:33 AM

> We really need to better define the various styles /
> implementations of OOP. Cause "it's a class, therefore
> it's OOP" doesn't really cut it for me. I'm going to coin
> two new terms.
>
> LOOP "Light" OOP (some might say L == lousy).
> e.g.: Typical Javabeans with little behavior and gobs of
> exposed data via getters and setters. Much behavior is
> held elsewhere in services or procedures, which ask the
> objects for data.
>
> SOOP "Strong" OOP (some might say S == superior)
> Behaviorally complete objects with little exposed data.
> . You generally ask the object to do something, not to
> tell you it's data.
> e.g.: Take an OOAD class, read Allan Holub or the Naked
> Object people.
>

I guess I'd prefer to use:

OOOP "Optimum" OOP choosing the best balance of encapsulation and data exposure to meet the goals of minimizing complexity and maximizing code reuse.

The problem with carrying SOOP to the extreme is that you end up maximizing the embedding of system-specific information in all your classes. You also limit the ability to reuse those classes because new uses that require access to some representation of the internal state can't be implemented outside the class.

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.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Gavin King: In Defence of the RDBMS

Posted: May 31, 2007 11:44 AM

> James - yes, I was in a good mood this morning.
>
> Maybe we should write a "Good Cop / Bad Cop" OOP article?
> :-)

I don't wan to imply that there is one true way to do OO. There are actually tow distinct schools that have very different ideas about what OO is: the SmallTalk school and the C++ school for lack of better terms. JavaBeans are IMO the unholy love child of these two schools. All the problems of both with few of the benefits of either.

Even inside the C++ school there are some different ideas that I won't say are wrong even though I have strong opinions about them.

But there are some things that are just plain not OO. And it's coming from places a lot of people consider to be full of experts. A blue place that is not small, for example.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Gavin King: In Defence of the RDBMS

Posted: May 31, 2007 11:48 AM

> 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 ultimately disagree with it.

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

Previous Topic

Next Topic