Re: ODB (Cache?) vs ORM

• Previous message: Bjorn Abelli: "Re: what is the meaning of Degree of derived table does not match column list"
• In reply to: Lee Fesperman: "Re: ODB (Cache?) vs ORM"
• Next in thread: Lee Fesperman: "Re: ODB (Cache?) vs ORM"
• Reply: Lee Fesperman: "Re: ODB (Cache?) vs ORM"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Sun, 13 Mar 2005 23:52:21 +1100

Lee Fesperman wrote:
[snip]
> I'll try to avoid repeating myself, but it will be hard...
>
> Integrity constraints need to be declarative and placed in the DBMS; not buried in
> procedural code and in applications. This is common and accepted database knowledge. The
> other way is error-prone, thus virtually guaranteed to break integrity, producing
> 'garbage'. One of the major purposes of normalization is to avoid redundant facts, which
> destroys integrity. Normalization only makes sense under RM.
>
> As I stated earlier, OO has no data model. It can't avoid misplacement of facts to the
> detriment of integrity. No amount of 'constraints' will prevent that.
>
> Lastly, declarative constraints can be optimized by the DBMS. Declarative optimization
> is multiple orders of magnitude more powerful than procedural optimization.
[snip]
> Without a proper structure, transactions are a joke. Even OO experts
will disagree
> whether a given object design is proper.
[snip]
> It is more than just physical schema migration. RM provides tools (like views) at the
> logical level to ease the transition and prevent errors.
>
>
>>>+ There will never be any ad-hoc querying or reports.
>>
>>As said before, object databases can provide a relational view on the
>>data. This is exactly what Caché does.
>
>
> Only by using navigation, which robs all the power.
[snip]

> Non-relational system provide multiple ways to get to the data. This is true complexity.
> Some data can only be reached with just one of those ways. If you don't know what that
> is, you can't find the data. Navigational access forces arbitrary indirection and
> linking to reach some information. If you don't know the physical (not logical) path,
> you'll never get there. Since the path involves meta-data (physical links) rather than
> real data, it's quite easy to misplace information. Take a look at that mess called XML.
>
> All atomic data in RM can be reached with 3 pieces of information --- the table name,
> the column name and a primary key value. Normalization makes sure it all makes sense.
>
> I once heard an anecdote that Codd (the father of RM) asked a DBA of a network database
> about a certain piece of information. The DBA had to confess that he didn't know how to
> retrieve it.
>
>
>>Oh BTW, last time I used an object database it had a very good adhoc
>>query interface, but nevermind.
>
>
> Undoubtably, it was not declarative and required navigation. It couldn't have been very
> good.
>
>
> These ideas and concepts have been around for over 30 years (and subject to intense
> research), yet OODB builders choose to ignore them for no other reason than hubris. I'd
> love to hear any one of them explain their rationale for disregarding even a single one
> of those principles.
>
> RM is absolutely the dominating data model for databases. Do you think everyone is just
> stupid?

No, I don't think everyone is stupid, but I know for sure that there are
times when people accept the dominant technology simply because it /is/
the dominant technology. I also know from experience that people develop
a religious zeal for their preferred technologies, and it seems to me
that you are a case in point.

The more I read of your arguments, the more I realise that they don't
apply to Caché. I've only been playing with it for a few days, but I
suspect that you've never even looked at it. Instead, you keep repeating
arguments against the ODBs you /have/ seen and choose to believe that
those arguments are universal.

Caché is based on sparse arrays, not the network model. While it doesn't
possess a data dictionary, there is a natural organisation to the
classes (tables to you) and it's easy to add optimisations by extending
those classes with indices. It's /always/ possible to access a given
class/table by its primary key at the very least, and it's far easier
and more natural to define the data relationships that it is for the
relational model.

Moreover, there is an automatic mapping in Caché to SQL. It's not
grafted on afterwards. As soon as a class is defined, it is available
via JDBC/ODBC by use of SQL. Lists and arrays embedded within a class
are externalised to related tables.

IME one of the biggest hurdles to optimisation is complexity. The more
abstruse and unnatural the toolset, the less likely it is that the
practitioners will achieve a satisfactory and efficient solution. If
relational databases can only provide optimum performance when it's
tuned and attended by a full-time specialist DBA, I'd say it has failed
the test of complexity. And this seems to be all-too-often the case.

Luke

• Previous message: Bjorn Abelli: "Re: what is the meaning of Degree of derived table does not match column list"
• In reply to: Lee Fesperman: "Re: ODB (Cache?) vs ORM"
• Next in thread: Lee Fesperman: "Re: ODB (Cache?) vs ORM"
• Reply: Lee Fesperman: "Re: ODB (Cache?) vs ORM"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]