Re: Is mysql a RDBMS ?

"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.

With all due respect to Lauri, you contradict the above insincere flattery in the remainder of your response. This is only further evidence of your lack of integrity and of your intellectual dishonesty.

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. Your argument is, once again, nothing more than intellectually dishonest sophistry. Like a typical vendor, you rely on the ignorance, prejudice and ineptitude of an untrained marketplace to try to appear to have a legitimate counter, but it is only an appearance and only to the ignorant.

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!

> "Lauri Pietarinen" <lauri.pietarinen_at_atbusiness.com> kirjoitti viestissä
> news:bire7g$md8$1_at_nyytiset.pp.htv.fi...
> > Hi Heikki,
> ...
> > >of course self-joins occur in real-world applications. But we are still
> > >waiting for you to provide a real-world example where the join size is
> > >bloated with duplicate rows.
> >
> > I sympatize with you wanting to see a real world example demonstrating
> > the usefulness of
> > working with relations instead of bags regarding optimisation and it
> > took me a while to find
> > an (in my view) convincing example.
> >
> > I posted this previously and have pasted it here for easy reference:
> >
> >
>
http://groups.google.com/groups?q=g:thl3922164456d&dq=&hl=en&lr=&ie=UTF-8&se lm=3E625162.4060203%40atbusiness.com&rnum=23
> >

[snippage]

> > Is this a useful view? It sure is!
>
> I assume you mean the big view which joins S, SP, P. It kind of
> denormalizes. That is why duplicate rows of P appear.
>
> > Could I actually provide such a view
> > to my end users or programmers?
> >
> > No I can't, because they have to
> > 1) remember to use DISTINCT
>
> Hmm... there is at least one additional reason not to provide such a view
to
> programmers. Since it is denormalized, they might try to update the
> attributes of a supplier for just one row, receiving an obscure error
> message about the non-updateteability of the view. Or, they could try to
> insert into the view.
>
> Another reason is that it is not an outer join. There may be parts which
> currently have no supplier. Users might be misled to thinking that the
above
> query gives all parts, not just the parts supplied by somebody. Of course,
> these are well-known problems of a denormalized database.

In other words, you contradict your flattery above. Received on Sun Aug 31 2003 - 16:42:30 CEST