Re: Pizza, anyone? Was:Real world issue: How to "split" queries in presence of record replication and replication sensitive aggregate functions ?
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