Does ROI ring a bell?

If you can prove OODB is easier/faster/larger/cheaper than commercial RDBMS,
most managers would agree on moving their databases. I have not seen that
happening, maybe there are lots of good products, but they are not giving
away their merchandise like Sun did with Java. Ok, Sun is struggling now, so
maybe it is a bad example.

OTOH it is amazing how many projects now use Java. Also it is amazing that
nobody has come up with a good OODB for use with Java, seizing that
opportunity.

Cheers,
Guillermo.

"H.Y.Lui" <hylui (AT) netvigator (DOT) com> escribió en el mensaje
news:bc9u01$5r636 (AT) rain (DOT) i-cable.com...

"Guillermo Schwarz" <guillermo_schwarz (AT) hotmail (DOT) com> wrote

What are you talking about "nobody has come up with a good oodb for use with
Java"? See: http://www.firstsql.com/

"Bob Badour" <bbadour (AT) golden (DOT) net> escribió en el mensaje
news:UaxVa.1416$705.255588495 (AT) mantis (DOT) golden.net...
EXISTS clauses were considered harmful by C.J. Date.

But I haven't seen any reference about FirstSQL being an OODBMS. How is it
different from using MySQL or HSQLDB? In what respect is FirstSQL an object
database? Can you show us some code?

The main idea about having OODBMS, if I remember correctly, was to have
databases with data AND behavior. Then databases included stored procedures,
and by no means that meant that databases had behavior. Some argue that
having a query language is more important, others argue that complex
relationships can't be adequately modelled using RDBMS. IMHO both are
correct, since so far one size does not fit all.

"Guillermo Schwarz" <guillermo_schwarz (AT) hotmail (DOT) com> wrote

See FirstSQL/J

Guillermo Schwarz wrote:
I'm glad you found the site informative. FirstSQL is the only DBMS that has solved the
EXISTS problem.

Unlike MySQL or HSQLDB, FirstSQL/J provides integrated support for objects. In
FirstSQL/J, table columns can have an object class as their datatype. The value of an
object column can be an instance of its defined class or one of its subclasses.

FirstSQL/J extends SQL to allow you to call the methods of object columns. A simple
query example:

SELECT shape FROM shape_table WHERE shape.getHeight() < 14;

Object columns have data (fields in the object) *and* behavior (methods in the object).
Extended object capabilities enhance the strengths of SQL.

Complex relationships can be stored in object columns, but we encourage the use of
relational facilities for modeling complex relationships. As OODBMS proponents have
discovered, accessing complex relationships using object structures is too difficult.

You are misinformed in stating that RDBMSs can't adequately model complex relationships.
This is where the relational model excels.

--
Lee Fesperman, FirstSQL, Inc. (http://www.firstsql.com)
================================================== ============
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)

FirstSQL/J certainly delivers a good Java ORDBMS that easily takes advantage
of OO and SQL RDBMS. The simplicity of using Java classes as objects along
with the methods, both simple and complex, in the database without special
treatment or 3rd party O/R tools is where the future of database technology
is leading.

Go ahead - feel free to seize the opportunity.

www.firstsql.com

Dave M.
"Guillermo Schwarz" <guillermo_schwarz (AT) hotmail (DOT) com> wrote

"Lee Fesperman" <firstsql (AT) ix (DOT) netcom.com> escribió en el mensaje
news:3F2F3FD1.771B (AT) ix (DOT) netcom.com...
Thanks for the example, that's a very simple example though. For example if
a shape can be a triangle, an square, a rectangle, a circle or a polygon,
the last query would run unchanged. We could do the following query:

SELECT shape FROM shape_table WHERE shape.getArea() < 100;

And we could create ShapeList extending Shape, so that complex structures
could be accessed using the same queries.

How does it version the classes?


So we need O/R mapping anyway, right.
RDBMSs can model complez relationships as long as the reference from one
table to the other is fixed. If you want to model the shape hierarchy the
RDBMS model becomes messy, IMHO.

Cheers,
Guillermo Schwarz.

Guillermo Schwarz wrote:
That's the point of the previous paragraph -- "The value of an object column can be an
instance of its defined class or one of its subclasses."

Versioning capabilities are currently limited, but this is not as big an issue. See
below.

Yes, you often would. However, an ORDBMS provides 'native' mapping capabilities. See my
article on byte.com -- http://www.byte.com/documents/byt1043081505209/ (it's free, but
you have to register).

Actually, mapping is a natural requirement. The needs of a persistent, shareable
datastore are different from needs of an individual application. This is discussed in
the article (also available in pdf at http://www.firstsql.com/NativeWrappersA.pdf, no
registration needed).

I just modelled that using a relational domain. How is that messy?

You have a limited view of the model. Relationships do not have to be fixed in
relational. An RDBMS is uniquely capable of handling dynamic relationships. It's the OO
model that tends to be inflexible and overly complex (messy).

The OO model has a bunch of ways of handling relationships -- is-a, has-a and various
ad-hoc techniques with only vague guidelines as to which to use. This is complex and
rigid. You also have to worry about direction in relationships.

The relational model has exactly one way to represent relationships --- as values in
tables (actually, in relations). Blindly simple and powerful at the same time.

That's why versioning is so crucial in OO designs. You never have a clue whether you did
it right.

--
Lee Fesperman, FirstSQL, Inc. (http://www.firstsql.com)
================================================== ============
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)

"Lee Fesperman" <firstsql (AT) ix (DOT) netcom.com> escribió en el mensaje
news:3F399B2D.447B (AT) ix (DOT) netcom.com...
Yes, in an OO model that's true. That's is not the case though in the
relational model. A triangle, a square and a circle would be stored in
different tables, not in the same table as in a OO database.
It asked me to register and it was not free, therefore I couldn't read it.

The fact that you need mapping means that individual fields in a class must
be mapped to fields in a table. But a field in a class may dynamically refer
to different classes in an object model, that is not the case in the
relational model.
Can you show us the resulting model?


Can you show us some example?

The relational model does not have direction in relationships?
Do you mean you never change your relational database model? Once done it is
cast in stone?

Cheers,
Guillermo Schwarz.

"Guillermo Schwarz" <guillermo_schwarz (AT) hotmail (DOT) com> wrote

You are not listening to Lee. In the relational model, a relation might
represent a triangle, a square and a circle in the same attribute of
different tuples in a singe relation. In fact, Lee's product is more
relational than other SQL products, and it allows exactly the above. (Your
uneducated declarations notwithstanding.)


Lee, Guillermo is right about the fee. The least expensive option is almost
$20 US.


Again, your opinion expressed above is incorrect. You simply do not know
enough about the relational model, and subsequently you suffer from common
prejudices and misconceptions.


He already did. Can you understand relatively simple english?


If you have to ask, you have not sufficiently educated yourself on the topic
of data management to make credible public declarations or to make demands
for remedial online education.


No, it does not. If you educated yourself on the most basic data management
facts, you would already realize that relationships expressed by like values
in the relational model are symmetric.


No, he does not mean that. You need to prepare better.