cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject Re: DB support in flowscript (was: XSP "official" position)
Date Fri, 21 Nov 2003 11:43:00 GMT
Leszek Gawron dijo:
> On Wed, Nov 19, 2003 at 01:36:17PM -0600, Antonio Gallardo wrote:
>> >> >   - sometimes the db schema makes it impossible to use O/R tools
>> Show me one. This also denote SQL can be abused. Just for the records,
>> we
>> are currently building an accounting system and O/R works fine there.
>> This
>> is the example you said: a 150+ tables.
> see

See also the answer to them:

I was reviewing old mails and also found the link to the mail you linked
above. At that time, I choosed not answer, because there was already an
answer and it was enough to me. Today, while reviewing old mails, I
started a new answer to them, but choosed again to not reply and closed
the window. It was an old enough mail and tought you already has another
opinion to this. But:

1-Any wrapper around any database is slower than direct native DB access.
This is a fact. Here I can easily include JDBC, ODBC, etc. When we add any
additional instruction for processing, often it is slower.
2-O/R mapping is just an approach to fill the gap between SQL world and OO
world (in this case java).
3-Any of the given models you provided in the linked mail can be easily
converted to O/R mapping. I don't see why not. Note you saw the problem
from the SQL side and not from a OO side. And the view point is very
important to understand the solution. Note in O/R mapping you can choosed
the level of description. If in a given case you don't need a reference
descriptor, you simply don't implement it. That is all.
4-The DB schema 2 and 3 are just design decisions outside the choosed
implementation. Simply, it does not matter if I choose to implement with
XSP, Java, ODBC, JDO, ADO, DAO, ESQL, C++, C, etc.
5-Personally, I will choose the schema 1, because it is cleaner, easily
expandible and has more potential to solve new challenge. Try to explain:

What do you do, if your boss one day said:

"The management decided to add a new question".

How you would manage this in the schema 3? Hehe!

It would simply be a hell. I saw in schema 3 a bunch of "ALTER TABLE" that
innevitable will add 1,000s of empty fields just to make a "dirty patch".
And then? New request how will be solved?

Now the boss comes back again and said that they want to see a report
involving data accross the questionaries! It would be amazing to see the
KB long SQL string we will to send to make 10's of "JOIN"s... of course
the same apply for any O/R tool. This is just a design problem again.

But this RT are just related to design, regardless the implementation you
decide to use. It will be a hell for any of them.

My experience said me:

"Alway let them the path to grow (or "extend it"?). Users never stop
asking new things". (This is again regardless, the implementation).

Also, I believe in DB developers. They have hard time trying to find the
fastest algorithm to improve DB performance. So I will prefer the 2.5M
records + some indexes in ONE table and I am sure it would perform almost
as fast than the proposed schema 3 with +100 tables with less info.

...But note all this decisions are related just to design. No matter O/R
or SQL.

> The second case is :
> Imagine you have table that describes building (Building) and then you
> have a
> table that describes the flat (Flat).
> Now you want to assign tasks:
>  - visit the flat and do something
>  - visit the whole building (each flat in the building)
> so you add some more tables:
> Task
> TaskBuilding
> TaskFlat

This can be easily managed using the JDO concept: "extends" inside
classes. BTW, It is a tipical sample in JDO literature. Changes it to:
Employees, Managers, Developers, Sellers, etc. You can have a common base
class "Person". Then you can extend the base class "Person" to another
"Employee" and from Employee to Managers, Developers, Sellers, etc.

It is cleary an OO approach. This is what O/R tools do: allow us think OO.

> You also have to add a TaskBuildingFlatVisited table to be able to report
> which flats have already been visited if a task was for the whole
> building.
> Now the problem: you cannot generate a report simply if you do just
> inserts
> into the TaskBuildingFlatVisited table, just because you know which flats
> been visited and it is very hard to query the database for a negated set
> (the
> flats that have not been visited have no corresponding records in the
> database).

> So the solution is simple:
> You extend TaskBuildingFlatVisited table with a visited_status column. Now
> you
> create a trigger on TaskBuilding table that for each building task insert
> you
> insert all corresponding flat references to TaskBuildingFlatVisited. Now
> if a
> user visits a flat you do not insert a record - you UPDATE an appropriate
> one.
> So now if you want to query for flats that have not been visited it is
> really
> simple. But now the database adds/deletes rows from database behind your
> back.
> AFAIU this messes up OJB tool completely. Or am I wrong maybe?

:-D Yes, the last is true. OJB can easily manage this and you will not
have problems. Also you have DB cache and table proxies.

>> Who said O/R mapping need to be wroten by hand? This is not a MUST
>> anymore. This is mainly why I go to Druid. Did you know Druid? If not
>> here
>> is the link: :-D
> This link does not work :)
> I've been looking at druid but there is one problem: Druid uses some weird
> technique to detect a JDBC driver in provided jar file. The problem is
> that
> Microsoft SQL Server JDBC driver consists of 3 jar files and even if you
> edit
> the druid configuration by hand it does not detect the driver class.

Hmm... Another "MS game"? I wonder why your DB provider is so smart that
innovated in this area too. :-D ... sorry for the irony. :-(

Seriously, I don't use MS SQL Server. But I hear somewhere the JDBC driver
from MS is slow in OJB. Maybe this is the problem you feel and for this
reasons you are against O/R tools. I hear some people prefer some 3rd
party driver that works faster. Please note I don't use MSSQL, so I cannot
discuss about why and how. It was just a rumor I hear in OJB list: See the
link and the problems related to tables with 5 millions records with MS
SQL. Other people manage this without this type of problems in other
RDBMS. I think the link also show some people working with BIG tables and
O/R tools:

How can they work with so BIG tables with OJB? But they already are. ;-D

>> Using Druid making an O/R mapping is a matter fo secs! Is this a
>> problem?
>> Also + your Beans ready to be used. Well the Beans for JDO are a little
>> bit slower. But I am sure you will have in less than 2 mins you
>> database.jar ready to use. So where is the problem? :-DD
> If you advertise it so strongly I think I will have to try it but first I
> have
> to resolve a problem with the M$ JDBC driver.

I need to warning Druid support for OJB and JDO is just in diapers. Please
don't think it can manage any posible construction. There are some
constructions that it cannot manage, but we are working on.

But I can assure we easily builded 3 diferent databases with +100 tables
each one. So I think Druid can work for the most commons constructions.

Please don't take this mail as an attack. I understand everyone has his
own programming styles and it is often a trade off. I understand you
provided them just as samples to illustrate your points.

O/R tools are not perfect and there is soon a new JDO release 2.0 that
promise to solve some of the currently problems and enhance some weak
areas. But this does not mean you cannot use it right now.

At the end I need to said: "We are betting to O/R mapping". So we had hard
time learning all this new stuff and seems it can work and we will have a
really SoC at the end.

Sorry for this long answer.

Best Regards,

Antonio Gallardo

View raw message