Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]

From: vc <>
Date: 20 Jun 2005 13:43:12 -0700
Message-ID: <>

Jan Hidders wrote:
> vc wrote:
> >
> > In short, it appears that FDM uses the same data model as the OODB
> > does (ignoring minor syntactical and terminological differences, like
> > 'entity' vs. 'class').
> If you restrict yourself to the structural side of the data model, i.e.,
> how data is structured, then they are the same. (With the additional
> remark that we are looking at the pure OODB data model, for the impure
> model, as defined by e.g. IFO or the related IQL data model, the
> relationship is not that simple.) But in this case the query languages
> are wildly different; where Java is imperative DAPLEX is a declarative
> functional language.

In Java (assuming 'employees' is a collection):

for (employee emp : employees)

   System.out.print(emp.getName(), emp.getAge(), emp.getDepartment().getBuilding().getName())

How is it different from Daplex ?

> > "Navigational" is probably not a good word. I should have written that
> > a Daplex query produces items ('print') in an imperative way:
> >
> > for each s in employee
> > print(getName(s), getAge(s),
> > getName(getBuilding(getDepartment(s))))
> What's imperative about this? Where are the assignments? Where are the
> while loops?

Why, the 'print' word of course as I wrote earlier.

> > ... which might make one to assume a mental navigational model for the
> > entire language, rather than declarative/functional ['functional' as
> > in functional programming] one.
> If your above example would be written in ML it would look roughly the
> same.

I am sure you know that ML is *not* a pure FL and the fragment in question would be imperative there too thanks to 'print' or whatever ML uses.

>There is really nothing imperative about it and I am somewhat
> astonished (and with me probably the largest part of the functional
> programming language research community) that you think there is.

See above.

> Defining views might be, but it's not
> clear to me how deep that problem is. What exactly would a "view" be in
> this context anyway?

You tell me ;)

> > [...] I'd be interested, though, to understand what the FDM has to
> > offer that might be different from the OODB approach.
> If you define "the OODB approach" roughly as "a graph-based data model
> with a declarative query language" then my answer would be a clear and
> firm nothing.

Thank you.


> -- Jan Hidders
Received on Mon Jun 20 2005 - 22:43:12 CEST

Original text of this message