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 ... 14 | » ]

Ravi Venkataraman

Posts: 80
Nickname: raviv
Registered: Sep, 2004

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 5:22 AM

Kevin, see Robert's earlier post.

Just because a significant number of web programmers design applications that permit SQL injection it does not follow that RDBMS are insecure. It is a trivial matter to take care of SQL injection: make sure there is no SQL code in your application, only references to keys that obtain the required SQL statement from some sort of configuration system (file, database, whatever.)

As Robert Young mentioned, this is a strawman argument. As I mentioned earlier, you can, in fact, have more fine grained access to data using RDBMS than for an OODBMS, including row-level security such as that provided by "Trusted Oracle" earlier.

Ravi Venkataraman

Posts: 80
Nickname: raviv
Registered: Sep, 2004

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 5:27 AM

Achilleas, what does the term normalization mean when referring to objects?

As far as I am aware of, the term normalization is conspicuous by its absence in every article and book on OO philosophy and practice.

What I've seen is an explosion of classes and class hierarchies with sub-classes only differing in the values that one or two fields may take, not in behaviour. And this seems to be a very common Java/J2EE design pattern (anti-pattern?). In short, bloat.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 6:19 AM

> The biggest mistake that OO programmers make is to start
> their design with the application and leave the database
> till last.

Designing the perfect DB structure first is one approach. But not very Agile.

> 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.

I'm unaware of any "normalize" refactoring tools for OO languages. Are there any? If not, probably worth doing.

> I have a separate class for each database table.
...
> The advantage of using a separate class for each table is
> that all the rules for making changes to that table are
> held in that single class.

Agreed. And your objects know (at least indirectly) how to CRUD themselves. Which I also believe is a good thing, though we are in the minority here.

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.

Ravi Venkataraman

Posts: 80
Nickname: raviv
Registered: Sep, 2004

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 6:52 AM

Morgan said: "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."

Why should everything be OO? OO is just one way of doing things. If the job requires something non-OO, if it makes more sense, why not use it?

We should ask ourselves the question: What is our objective as software developers? Is it to use OO in every project? or is it to use the best method that seems to serve the needs of our customers?

If the latter, then the lack of "OO"ness is not an issue. My guess is that the Table class would be much more like one of the "helper" classes that proliferate any Java/J2EE application; the Table class would probably be something like a module in other languages.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 7:09 AM

> One of the most valuable lessons I learned years ago in a
> structured programming course was (a) get the structure of
> your database right, and (b) structure your code around
> the database. If the application structure and database

While this may work well much of the time, there are exceptions. There are types of data for which all relational representations are unpleasant to use. In these cases, while you can store the data in relational form, nobody will ever use that data directly via SQL, instead all access goes via the applications associated with it. In which case it doesn't matter what type of database is used as it is all effectively opaque. In addition you are better off designing the application(s) first and then data storage.

Tony Marston

Posts: 37
Nickname: tony32
Registered: May, 2007

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 7:21 AM

> As far as one table per class is concerned, I have two
> two questions. One, can the insert, update, delete
> operations for table-classes be generalized so that we
> have one class per application that accepts a table name
> and class name (or gets one and infers the other) and
> performs the required CRUD operation?

The idea of one class per application is never something that I would advocate, never in a million years. Every user transaction knows which tables it needs to access, so to my mind it is easier to instantiate an object from the relevant table's class and invoke a method on that object than it is use a generic class and use the actual table name as an argument in the object's method.

> The second question
> is - why not use views instead of tables so that table
> structure changes are insulated from any application
> code?
>

It may be possible to use views in some cases, but at some point in time any changes you make to the database structure must be communicated to the application. That is the benefit of my approach - change the database structure, press one button to import those changes into the data dictionary, then press another button to export the changes to the application. Easy peasy lemon squeezy.

Tony Marston

Posts: 37
Nickname: tony32
Registered: May, 2007

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 7:24 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.

Tony Marston

Posts: 37
Nickname: tony32
Registered: May, 2007

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 7:33 AM

> > I have a separate class for each database table.
>
> 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.

Some (OK, a lot) of OO programmers dislike my approach because it is different from what they have been taught. One table per class? No real OO programmer would do that! It is not "pure" enough! That's all BS as far as I am concerned. My approach works, and works well, and knocks the spots off many other methods I have seen.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 8:00 AM

> Some (OK, a lot) of OO programmers dislike my approach
> because it is different from what they have been taught.
> One table per class? No real OO programmer would do
> that! It is not "pure" enough! That's all BS as far as I
> am concerned. My approach works, and works well, and
> knocks the spots off many other methods I have seen.

It seems to me that this only works if the programmer has control of the database schema. Most of the time, I am working with preexisting tables that may be denormalized or just plain poorly designed. I know your prerequisite is that the database is perfect but what's your contingency plan?

I worked on a project where we derived all our classes from the database tables. It almost buried us because the tables were not normalized. After the first version of the (rewrite) application, the data modeler decided that the table needed to be normalized.

So I think that if the database is perfectly normalized, your approach will work but in reality most projects do not have this luxury. In addition, you've coupled your application code to the structure of the database. If the database is changed, it means you either have to redesign your classes or you need to have some sort of mapping to the new structure. I think in most cases, the mapping is going to prove to be the more feasible approach.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 8:12 AM

> Has Gavin ever used db4o? It would really open his eyes.
> (And, for all his talk of objectivity, looks like he
> e works for Hibernate)

That Gavin King works for Hibernate has to be the understatement of the month.

I know that Mr. King did not specifically mention Ted Neward in his blog post but I think it's no coincidence that this was posted now. It's clear (to me) that this is meant to be a rebuttal of Ted Neward's "Vietnam" papers.

Given the above, Mr. King's argument is a big red herring. Ted Neward does not say that the OODBMS can replace the RDBMS for all purposes. He actually states that it does not in the paper.

Personally, I think the RDBMS is pretty indispensable (for now anyway) and I'm pretty dubious about the use ORM in a lot of cases, at least in the way I've seen it implemented.

RDBMS does not imply ORM and a defense of RDBMS is not defense of Hibernate or any other ORM tool.

Ravi Venkataraman

Posts: 80
Nickname: raviv
Registered: Sep, 2004

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 8:21 AM

>
> It seems to me that this only works if the programmer has
> control of the database schema. Most of the time, I am
> working with preexisting tables that may be denormalized
> or just plain poorly designed. I know your prerequisite
> is that the database is perfect but what's your
> contingency plan?
>

I agree. But then, why do we, as software professionals, accept low quality work so readily? Should not the managers and most professionals be more cognizant of good practices? Shouldn't we build "SOFT"ware, that is easy to change and maintain?

The answer to the supposed mismatch problem is not just to build ORM layers to hide the poorly designed data-model, but to insist on a good data-model and then use the simplest approach that works.

>
> In addition, you've coupled your
> application code to the structure of the database.

That was the whole point of the suggestion about using views. The internal structure of the database is hidden by the views serving as an abstraction layer. Changes made for database-management related reasons do not affect any application layer; and there is no tight coupling between the application layer and the data-model.

>If the
> database is changed, it means you either have to redesign
> your classes or you need to have some sort of mapping to
> the new structure. I think in most cases, the mapping is
> going to prove to be the more feasible approach.

Well, this technique of forcing change in one part to affect all other parts that use it means that what we have built is no longer "SOFT"ware.

And I certainly want no part of it.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 8:41 AM

> >
> > It seems to me that this only works if the programmer
> has
> > control of the database schema. Most of the time, I am
> > working with preexisting tables that may be
> denormalized
> > or just plain poorly designed. I know your
> prerequisite
> > is that the database is perfect but what's your
> > contingency plan?
> >
>
> I agree. But then, why do we, as software professionals,
> accept low quality work so readily? Should not the
> managers and most professionals be more cognizant of good
> practices? Shouldn't we build "SOFT"ware, that is easy to
> change and maintain?
>
> The answer to the supposed mismatch problem is not just to
> build ORM layers to hide the poorly designed data-model,
> but to insist on a good data-model and then use the
> simplest approach that works.

In my case, there's many hundreds of thousands of lines of code referencing the schema. Most of the schemata are not even under the control of my organization.

What do you suggest? Should I refuse to do any work until the database is changed? This is professional? Professionals make things work even with the conditions are not perfect.

> > In addition, you've coupled your
> > application code to the structure of the database.
>
> That was the whole point of the suggestion about using
> views. The internal structure of the database is hidden by
> the views serving as an abstraction layer. Changes made
> for database-management related reasons do not affect any
> application layer; and there is no tight coupling between
> the application layer and the data-model.

Views can be useful but are by no means a panacea for data-modeling issues. And in reality, this becomes your mapping layer. It's no longer a question of mapping or not if you are talking about views. Now the debate is over the pros and cons of different mapping strategies which should include utilities of the database and tools outside of it.

> >If the
> > database is changed, it means you either have to
> redesign
> > your classes or you need to have some sort of mapping
> to
> > the new structure. I think in most cases, the mapping
> is
> > going to prove to be the more feasible approach.
>
> Well, this technique of forcing change in one part to
> affect all other parts that use it means that what we have
> built is no longer "SOFT"ware.
>
> And I certainly want no part of it.

So now you agree with me? I thought that you were arguing for this strategy above.

Ravi Venkataraman

Posts: 80
Nickname: raviv
Registered: Sep, 2004

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 9:00 AM

My point is simple: Whenever possible, design something in a flexible way. The suggestion of one class per table did not seem flexible enough to me. Which is why I inquired about alternatives.

My question about accepting low quality work was directed at the managers and team leads who insist on hurrying everything, often do not recognize a good idea, and end up encouraging shoddy work. We developers often feel frustrated when we see such work and are asked to work on it. As professionals (and possible bread winners for our families) we have no choice but to hold our nose and do the job.

Things change, that is a given. That is why I keep insisting on the "soft" part of software, so that we can easily handle change. Using views is one way of changing tightly coupled code to loosely coupled code; and of avoiding ORMs.

My focus is on creating "soft"ware applications, and reminding developers that that is what we do, create "soft"ware, a message that seems to been forgotten by the vast majority of developers.

Ravi Venkataraman

Posts: 80
Nickname: raviv
Registered: Sep, 2004

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 9:15 AM

I had suggested using views as an abstraction layer, not as a mapping layer. It is not a mapping from table(s) to a class, though, in effect, it comes down to the same. The point is that the view represents the business need, not necessarily the class's view of the data.

The key is that different applications can use different views based on the same underlying data structures. If the application requirements change, or the classes change, then we can always change the views without affecting the internal database structure. For example, let us say that our Person class now needs the home address of the person. Just change the person_view to fetch the home address. The class has changed, the view has changed, yet it has not affected the underlying data structures. In this sense, views can be used to serve as an abstraction layer, hiding the data structures form the application.

At the same time, we can change the internal representation of the database for whatever reason, and change the views to conform to the new internal representation without any application needing to know of this change.

Seen this way, the view is more of an interface between the application layers and the database; just like stored procedures and functions should be. Interfaces, as we all know, should not change very frequently. The implementation of the interface can change as often as needed, without affecting the applications that use it.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 9:17 AM

> My question about accepting low quality work was directed
> at the managers and team leads who insist on hurrying
> everything, often do not recognize a good idea, and end up
> encouraging shoddy work. We developers often feel
> frustrated when we see such work and are asked to work on
> it. As professionals (and possible bread winners for our
> families) we have no choice but to hold our nose and do
> the job.

I agree that we too much shoddy work is accepted and we that know better should push back more often. But I've often had to work with things that were done long before I was around to push back. I've worked on systems where none of the original developers are still around. The question then is what is the most effective way to produce a quality outcome. Generally speaking, the effort to restructure the db from scratch is going to be too great to justify.

Perhaps I misunderstood the point of your post.

> Things change, that is a given. That is why I keep
> insisting on the "soft" part of software, so that we can
> easily handle change. Using views is one way of changing
> tightly coupled code to loosely coupled code; and of
> avoiding ORMs.
>
> My focus is on creating "soft"ware applications, and
> reminding developers that that is what we do, create
> "soft"ware, a message that seems to been forgotten by the
> vast majority of developers.

It's interesting to me that you say this. I've been thinking this same thing lately. I see a lot of systems being developed as if they will never change. I mean really bad stuff like hard-coded keys to logic branches. This assumption never proves to be true and we suffer every day because of it.

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

Previous Topic

Next Topic