Re: Is mysql a RDBMS ?

"Heikki Tuuri" <Heikki.Tuuri_at_innodb.com> wrote in message news:%5p4b.206$TR6.15_at_read3.inet.fi...
> Hi!
>
> "Bob Badour" <bbadour_at_golden.net> kirjoitti viestissä
> news:SYo4b.219$aF4.27198535_at_mantis.golden.net...
> > "Heikki Tuuri" <Heikki.Tuuri_at_innodb.com> wrote in message
> > news:MHi4b.46$TR6.27_at_read3.inet.fi...
> > > Lauri,
> > >
> > > thank you! We get input to this discussion from a person who really
> knows
> > > practical database applications.
> ...
> > Your petulant demands for a "real world application" involving
duplicates
> > are nothing but the worst kind of sophistry. You demand something from
me
> > that you have the burden to prove.
>
> the question was to show that it is easier to optimize queries in a
> mathematical relation language, like the relational algebra, than in a
> multiset language, like SQL. Demanding real-world evidence for a
scientific
> claim is not sophistry.
>
> ...
> > The ignorami who suggest a use for duplicates often stupidly cite the
> > example of a grocery receipt, which is only a physical report of course.
> > However, as a means to demonstrate the stupidity and dishonesty of your
> > petulant demands, I suppose it will do.
> >
> > Consider the following base structures:
> >
> > A -- items purchased
> > M -- units of measure
> > P -- product catalog
> >
> > In your real world, A contains a multiset where three identical rows
> > describing cans of soup indicate the customer purchased three cans. In
my
> > real world, A contains a set of tuples where a single tuple describes
> three
> > cans of soup with the integer value, 3. For simplicity, M contains a set
> of
> > units of measures in both real worlds, and P contains a set of products
in
> > both real worlds.
> >
> > Consider the following views or derived structures:
> >
> > AM = ( A JOIN M )
> > AP = ( A JOIN P )
> >
> > In a real world application, a real human user wants to report on the
> items
> > purchased using english descriptions to describe the units of measure
and
> to
> > describe the products. The real human user naturally uses the views:
> >
> > R = ( AM JOIN AP )
> > = A JOIN M JOIN A JOIN P
> > = ( A JOIN A ) JOIN ( M JOIN P )
> >
> > In my real world, the ( A JOIN A ) part of the query is simply ( A ). In
> > your real world, the ( A JOIN A ) part of the query either changes three
> > cans of soup into nine cans of soup or into one can of soup, and this is
> > exactly the example you claimed is not a real world example. Duh!
>
> Hmm... how humans really think in this case?
>
> The grogery list A joined to M looks like this:
>
> xyz 500 ml (metric milliliters)
> xyz 500 ml (metric milliliters)
> xyz 500 ml (metric milliliters)
>
> The grocery list A joined to P looks like this:
>
> xyz CAN OF SOUP produced in China
> xyz CAN OF SOUP produced in China
> xyz CAN OF SOUP produced in China
>
> Now I want to 'join' these two lists. I pick an item from the first list,
> look for a row containing xyz in the second, and look where it is
produced.
> Thus we are kind of using the fact that AP = A JOIN P and we extract the
> relevant part of P from AP by using a kind of GROUP BY.
>
> Then we calculate AM JOIN (AP GROUP BY P) to produce the list:
>
> xyz CAN OF SOUP 500 ml (metric milliliters) produced in China
> xyz CAN OF SOUP 500 ml (metric milliliters) produced in China
> xyz CAN OF SOUP 500 ml (metric milliliters) produced in China
>
> Of course, this does not really show anything about optimization of
> real-world database applications, because both in a multiset language and
in
> a mathematical relation language we normally either add a quantity column,
> whose value in this case is 3, or assign unique id's for each row. Then
the
> query and its optimization is the same in both types of languages.

With all due respect, you have just argued against multisets. You have demonstrated they impose both computational and cognitive burdens while arguing they have no practical use in the first place.

> Suppose our cans have each a serial number. Then the list looks like this
>
> 785756 xyz CAN OF SOUP 500 ml (metric milliliters) produced in China
> 785757 xyz CAN OF SOUP 500 ml (metric milliliters) produced in China
> 785758 xyz CAN OF SOUP 500 ml (metric milliliters) produced in China
>
> Suppose we want to remove the ugly serial number column. We perform a
> projection which removes it from the output.

Since the user can simply omit the serial number from the external output device without first performing a projection, you assume the user will perform unecessary work while in reality most people try to minimize work. Further, you took an example predicated on the indistinction among cans and then create a straw man by imposing an artifical distinction. The logically equivalent set-based solution involves a single row with a quantifier and no meaningless, uninteresting serial number.

Your latest argument is only further sophistry as I have come to fully expect.

You began by claiming relational is not well defined. You clearly established your intellectual dishonesty by repeatedly refusing to acknowledge the formal definition while trying to divert attention to informal rules of thumb instead.

Cornered by your own sophistry, you then shifted to a pretension that you originally claimed 'dbms' rather than 'relational' is not well defined because 'dbms' has no formal mathematical definition -- without establishing any need for such formality. You avoided the question of what constitutes a dbms while pretending to have an answer to the question somewhere. Lee provided a succinct list of requirements. You are welcome to critique Lee's list or to demonstrate how your product meets the requirements given.

I continue to hold the impression that your product is not an rdbms because it is not a dbms regardless of any relational fidelity in parts of its query language. I also continue to hold the impression that your product does not compare favourably with other SQL products with respect to overall relational fidelity.

The relational model has a formal definition in the form of Codd's 1970 paper. Many extensions to the relational model have been proposed over the intervening years and many of these extensions have formal definitions as well. Date and Darwen have proposed an alternate formalism in TTM that is arguably more elegant while better meeting the goals Codd set for the relational model in the 1970 paper. Date and Darwen further provide a start to formalizing many issues that are orthogonal to the relational model by suggesting the direction in which those formalisms should proceed.

You are welcome to continue to argue that your product is an rdbms, but I will only see those parts of your argument others decide to reply to. It is now time for me to invoke Date's Principle of Incoherence; actually, the time is long overdue. I am now putting you were you belong: in my twit filter with other mindless vendor automata like Neo. Received on Sun Aug 31 2003 - 19:09:45 CEST