Re: Is mysql a RDBMS ?

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.

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. In a multiset language we get:

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

In a mathematical relation language we get:

xyz CAN OF SOUP 500 ml (metric milliliters) produced in China

Oops! We lost 2 cans of soup.

Best regards,

Heikki Tuuri
Innobase Oy
http://www.innodb.com
Foreign keys, transactions, and row level locking for MySQL InnoDB Hot Backup - a hot backup tool for MySQL Received on Sun Aug 31 2003 - 18:10:35 CEST