Re: Is mysql a RDBMS ?

From: Bob Badour <bbadour_at_golden.net>
Date: Sun, 31 Aug 2003 01:55:38 -0400
Message-ID: <Seh4b.208$hg2.24599700_at_mantis.golden.net>


"Mikito Harakiri" <mikharakiri_at_yahoo.com> wrote in message news:bdf69bdf.0308302000.1e199913_at_posting.google.com...
> Leandro Guimarăes Faria Corsetti Dutra <lgcdutra_at_terra.com.br> wrote in
message news:<pan.2003.08.30.11.17.56.505239_at_terra.com.br>...
> > On Mon, 25 Aug 2003 11:57:09 -0700, Mikito Harakiri wrote:
> >
> > > if relational theory would
> > > comprise all the math, not predicate calculus only.
> >
> > But why would one want that?
> >
> > BTW, the relational model is based on set theory (hence
> > relational) and predicate *logic*. It can make use of either
> > relational algebra, or relational calculus, or both.
>
> Once again, predicate calculus and set theory are just 2 tiny subjects
> in math. You are not implying that the all the rest of the math is
> irrelevant, aren't you?
>
> > > For example, how would
> > > you represent multivariate polynomial
> > >
> > > 3*x*y^2+5*x^3
> > >
> > > relationally?
> >
> > Again, why would one want that?'
>
> I want to answer some queries about a system of multivariate
> polynomial equations. For example I would like to know if there is a
> vector that satisfies all equations.
>
> > > The examples of
> > > (still) open research topics include view updates
> >
> > Nice of you to ignore the nicest view updateability model
> > proposed by D&D... or even worse, about thinking the difference
> > between their model and the angelic space is more important than the
> > one between their model and SQL!
>
> I'm ignoring it because view updates are as hard as equation solving,
> and D&D model suggests no insight into it.
>
> > The thing is, we're stuck with SQL
> > for now while there is a much better model available, and only one or
> > two small-time vendors striving for it. That it is not perfect is the
> > irrelevant issue here.
>
> Once again, we disagree how much better. Bob's party may be right, the
> industry is stupid, but not *that* stupid. If there were obvious
> benefits "the big 3" would be busy implementing tutorial D language
> already.

Benefits for whom, though? An ignorant marketplace? How does that motivate vendors to provide customers benefits?

> > > optimization
> >
> > D&D and others have again and again shewn that the relational
> > model is much more optimisable than SQL... we don't even need them
> > telling us so, as everyone who've used SQL is familiar with its
> > arbitrary restrictions, lack of logic etc that have a negative impact
> > on optmisation.
>
> Yes, you would certanly have more nice identities in the pure model.
> But this not necessarily mean expression transformation is the most
> important thing in the query optimization! For example, one of the
> fundamental difficulties is cardinality and selectivity estimation.

Which is totally independent of the logical model.

> Being able to handle corelated predicates correctly. Or making the
> cost function right. It is difficult no matter what model you use.

One ordinarily disregards issues unaffected by a choice when weighing the options. When comparing logical data models, some difficulties do not matter.

> > > multidimensional methods
> >
> > I'm not sure what do you mean, but it seems this is irrelevant
> > to RDBMSs and the model, being more on the application level.
>
> Spatial database: "How many roads intersect this area".

Assuming this area is 51:

WITH T1 = area WHERE areakey = 51

,  T2 = road JOIN T1
,  T3 = T2 WHERE overlaps(path, region)
,  COUNT(T3)

;

> > > constraint databases
> >
> > What's the problem here? Again not sure of your meaning, but
> > the relational models have a complete declarative integrity
> > constraints system.
>
> Those are generalisation of spatial. BTW, what D&D take on spatial
> databases?

I strongly suspect their take is the relational data model suffices as a logical data model to express, to manipulate and to manage spatial and constraint data. Received on Sun Aug 31 2003 - 07:55:38 CEST

Original text of this message