cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leon Widdershoven <>
Subject Re: Modular database component
Date Tue, 20 Apr 2004 08:25:39 GMT

> I will not be sure. Writing SQL code is always larger than using O/R
> mapping tools and we already know many developers have problem with SQL.
> They don't write optimal SQL queries. See slides 10-14:

I honestly do not care about the efficiency of my SQL. The database is
by far the fastest component. I do not think OJB can really optimize
a simple SELECT foo, bar from BLA; statement. There's just nothing to optimize!

I do think that when queries get a bit complicated, or when columns or
tables are related, such tools are much preferred to SQL as it is just
to easy to forget to do something. I'm not argueing that.

It's just the very simple stuff I'd like to keep simple. I have spent
somehwat more than an hour now to try to get a mapping for my database
auto-generated using the reverse-db tool of OJB. It just does not give
me my table definitions. So now I search for another tool. All that
takes time. Then comes a learning curve. And only then I can try to
integrate it into my program into what amount to
select fullname, username from auth where username='foo';
I think simple things should not large tools to handle. It only introduces
other bugs.

> I think the SQL does not fit well into the OO world. That was told over
> and over. The O/R mapping gives you the hability to work with tables as
> Objects. As a sample, you can use JXPath and write something like:

That's true. And javascript is not OO so the match is perfect:)
Again, I agree O/R can be really usefull, but it can also be
really overkill. If you start with a good working knowledge or O/R
it's quite logical to use O/R.
But if you're an expert in SQL, why throw that knowledge away?

> objectA.objectB.usersList.user[1].name
> This is great to use this kind of Objects inside JXTG or in other places.
> Once you start using it, you will see there is not way back to plain SQL.

>>And who on earth needs a bridge or relational mapping for
>>Select username, password from authentication where username = 'foo';?
>>If you already have OJB up and running it is logical to use that, but
>>to start learning OJB just for that???
> I wonder if when SQL was a top technology, people had the same arguments
> as you against SQL.

Yes, of course. No-one likes to revalue his knowledge like Enron shares.

And it was valid then, less valid now. Like SQL vs O/R nowadays. SQL has
a lot of existing knowledge and tools. O/R is only starting. Books and
tools about/for OJB are more difficult to find than for SQL. Which makes
the technology harder to use - even if it is both better, less error
prone and faster.

And 15 years from now I will probably just as hard say that we should not
go to a situation where the database uses both voice recognition andsemantic 
analysis on a recording or your voice to determine what you want from it,
and give you the results spoken on your cellular phone:)

View raw message