Re: Pizza, anyone? Was:Real world issue: How to "split" queries in presence of record replication and replication sensitive aggregate functions ?

From: <pamelafluente_at_libero.it>
Date: 15 Sep 2006 13:23:06 -0700
Message-ID: <1158351786.727933.139930_at_m73g2000cwd.googlegroups.com>


David Cressey ha scritto:
> I'm going to suggest that you take a look in a topic discussed in this
> newsgroup a year or two ago, concerning how to report on pizza orders,
> where each pizza ordered can have a set of cheeses (like mozarella, romano,
> etc.) and an independent set of toppings (like pepperoni, mushroom, etc.)

Thanks David. I found it:
http://groups.google.it/group/comp.databases.theory/browse_frm/thread/fe25e4b0d870d71f/76b79e9027398f7d?lnk=gst&q=CHEESES+dawn&rnum=1#76b79e9027398f7d

but nor read it yet.

> There is a remarkable similarity between the pizza order scenario and the
> example you provided us here to start the discussion.

I would like to keep the matter abstract and use examples (only) to validate or discard a possible systematic method to do what we want. But on the end the method must work with any possible example.

> Dawn was kind enough to show us all how a simple multivalued file was able
> to pull up a report very much like the one you outlined, with none of the
> difficulties attendant on the use of the relational model and relational
> joins. In particular, by avoiding joins, the MV model would almost surely
> avoid the replication that your totals are sensitive to.

Ok. Let's proceed in an ordered manner. First I would like to solbe the problem within a relational framework. After we have solved this first basic problem, we might try to confront it with other approaches.

Actually I would like to put both in actual code. If interested I will them send you or any other reader the code or the possible application.

>
> I am sure you and Dawn could carry on a spirited discussion on the subject
> of MV as compared with RM. You seem to have a great deal in common.

Who knows !? Perhaps he/she is reading!

> You both have a sharp eye for keeping things simple for the programmer, and
> on avoiding the inflexibilities that go with structure. That seems to be
> the thing that us poor benighted data architects and theoreticians always
> lose sight of, to hear programmers tell it.

Interaction is reciprocal enrichment. I am missing all the theory part, and focused to get things work.
As a programmer, my continuos effort is to make thing simple (divide et impera), in order to be able with increasing level of complexity. Usually in programming simplicity is a (painful) achievement. But I am only interested in solutions which result in a general implementation, capable to dial with any possible request from the user and any possible configuration of tables/relationships/output fields. Ah hoc or specific solutions are of no interest. They are however useful to infer the general method and to validate it.

> I look forward to a lively and entertaining dialogue.

Sure. Let's work on a common basis to avoid misunderstandings. I suggested to take Northwind and make example reports with aggregate-function-replication issues on it. But if you want to make another schema just propose it. I will build my own little access DB to make the experiments and try the algorithm.

It's important that be no ambiguity.

Thanks.

-P Received on Fri Sep 15 2006 - 22:23:06 CEST

Original text of this message