Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: Marshall <marshall.spight_at_gmail.com>
Date: 3 Jun 2006 16:52:14 -0700
Message-ID: <1149378734.130632.299240_at_h76g2000cwa.googlegroups.com>


Keith H Duggar wrote:
> Andrew McDonagh wrote:
> > Marshall wrote:
> > > The point that I'm trying to make is: how hard is it to
> > > do ad hoc analysis of a database when the database
> > > supports a SQL interface, vs. a custom C-function or
> > > Java-class API? There is a significant difference in the
> > > efforts needed, and in the degree of flexibility that is
> > > supported.
> >
> > Whilst I understand and agree with your point that ad-hoc
> > queries against Relational DBs are best done via SQL
>
> That is absolutely NOT what he said. Do you understand that
> "database that supports an SQL interface" and "Relational
> DBs" are NOT the same thing?

Well, it seemed as if his central point was to tell me about something Ruby could do, and that this was just an intro with the intent of setting it up such that his point about Ruby wasn't supposed to be a *counter* to what I was saying.

SQL vs. Relational is a big point for c.d.t., but this is something of a cross-cultural thread; I'd be happy if one person learned that persistence is not part of the definition of dbms.

> By the way Marshall, isn't it more appropriate to say DBMS
> here? As in "DBMS that supports an SQL interface"? Just
> curious.

I was on the fence about it, but ultimately went with "database", because I was trying to compare having access to dataset X in a SQL dbms accessed via SQL vs. dataset X in whatever storage accessed via a functional interface. The constant on both was "dataset X" so I chose "database", even though my phrase "database that supports a SQL interface" was really somewhat imprecise shorthand for "database in a SQL dbms accessed via SQL."

Marshall Received on Sun Jun 04 2006 - 01:52:14 CEST

Original text of this message