Re: Real world issue: How to "split" queries in presence of record replication and replication sensitive aggregate functions ?
Date: 15 Sep 2006 05:35:06 -0700
Message-ID: <1158323706.211856.230060_at_i42g2000cwa.googlegroups.com>
Alexandr Savinov ha scritto:
Thanks. Let's define a common "protocol" to discuss and interact.
> What is a replication sensitive aggregation function?
Terminology
Please feel free to replace the following with the *right* english
terminology.
1.
sum()
For "aggregate" function (please correct terminology if wrong) I mean
something like:
avg()
var()
or any user function that turns a bunch of values into a single scalar
...
This involves a group of record and requires a GROUP BY clause.
For "row function" I mean for instance a function defined Income - Expenditure, Age * AgeWeight, ... this is computed on each record. These functions are uninteresting for our purpose. Do not give us any problem.
"aggregate function" is in some sense the opposite to "row function"
2.
For instance:
For "Replication sensitive" I mean:
min()
count distinct ()
anything not influenced by the replication of values
...
> How do you define a partition (of tables and relationships)?
You have a partition when you separate the objects that are in a set into several subsets that have no common items.
>
> What do you mean by "record replication"?
I mean, for instance when you join 2 tables in 1-N relationship, the values on side 1 get "replicated" on the resulting table.
> Could you demonstrate how this procedure works using the following
Yes I will. But for ease of discussion and so that anyone here can follow and make observations. I propose to take a free standard well know database, easy to work with. I suggest to take Northwind for ACCESS. If you do not already have it it is a free download:
Make your request referring to those tables.
If this represent a problem in any way, I will work with tables you suggest. I will make a little access db. In such a case I need a precise description of fields, relationships and the fields (with possible functions) that have to be in the final report.
Number of records are irrelevant to our problems .
-P Received on Fri Sep 15 2006 - 14:35:06 CEST