cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agssa.net>
Subject Re: Modular database component
Date Tue, 20 Apr 2004 08:52:13 GMT
Leon Widdershoven dijo:
>
>> 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:
>> http://cvs.apache.org/viewcvs.cgi/*checkout*/db-ojb/contrib/ojb-dataccess.pdf
>
> 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 think there is always place for optimization. ie: Take advantage of OJB
proxies, etc. I think optimization is good. But it is OT.

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

You need to see the "power" of beans before tell that. It is really very
easy. And if you worry for writing (I was too). There are tools as
eclipse.org that allow you to build beans very easy. There an option that
allow you to automatically generate getter and setters for beans. Groovy
also is a step forward in that:
http://groovy.codehaus.org/beans.html

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

True, we miss the easy build wizards (as a friend of mine joked last
month). But this is the cost of using the lastest scream in technology,
right?

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

I don't said, "forget SQL". O/R mapping is a higher level as programming
in C(++) while I know assembler. You have the advantage you really know
what is going behind the scenes of the C code. and this is a big plus and
helps to solve problems and write more efficient code.

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

Yep. In fact this is the cost of using the lastest. I am aware of that. I
think being a early adopter is hard.

> 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:)

Nice glipse of the future. :-D

Best Regards,

Antonio Gallardo

Mime
View raw message