Re: Doing Summation on multiple criterias on the same column in a

>> Why do you assume that all flags are aggregations? <<

Not aggregations per se, but things set by events at a different level
of abstraction in the data model. Most of my postings have dealt with
things that should be deduced from simple facts within the schema
("John is eligible for a higher credit rating because he passed one of
several tests (predicates and formulas)" as opposed "We gave John a
higher credit rating by setting a flag and have no idea why!")

>> Consider, for instance, software designed to be sold to multiple businesses (rather than used in-house at a single one), so it has customization options stored in a one-row table, e.g. whether customer statements should list old charges individually until paid (open item) or roll them into a single "previous balance" amount (balance forward). This sort of yes/no answer is not aggregated from any other facts, but chosen directly by the user who initially configures the software. <<

Think about what you just described. Is it data inside the data model
for the schema? Nope. Configuration is SYSTEM LEVEL META DATA! You
cannot get much higher up the chain than that -- this is where
business rules, external legal requirements and stuff like that live.
It is set by the user because the database cannot configure itself at
that level. Typically, you are even beyond the Schema Information
Tables at that level.

Re: Doing Summation on multiple criterias on the same column in a single query

> several tests (predicates and formulas)" as opposed "We gave John a
> higher credit rating by setting a flag and have no idea why!")

And do you think the fact that John likes lemonade should be described by
other facts in the database (e.g. what town he spent middle school in)? Or
do you think maybe that is just a fact on its own, not derived from
predicates, formulas, aggregations, or relayed from other facts in any way?

Re: Doing Summation on multiple criterias on the same column in a single query

--CELKO-- wrote:

>>> Consider, for instance, software designed to be sold to multiple businesses (rather than used in-house at a single one), so it has customization options stored in a one-row table, e.g. whether customer statements should list old charges individually until paid (open item) or roll them into a single "previous balance" amount (balance forward). This sort of yes/no answer is not aggregated from any other facts, but chosen directly by the user who initially configures the software. <<
>
> Think about what you just described. Is it data inside the data model
> for the schema? Nope. Configuration is SYSTEM LEVEL META DATA! You
> cannot get much higher up the chain than that -- this is where
> business rules, external legal requirements and stuff like that live.
> It is set by the user because the database cannot configure itself at
> that level. Typically, you are even beyond the Schema Information
> Tables at that level.

I suppose you can define the aforementioned one-row table as not being
part of "the schema". Shrug.

In another message, you write:

> I have no trouble with a two-valued domain; I even gave an example of
> the Rh factor in blood typing. You just do not see them very often in
> the real world.

So what's the difference between a two-valued domain and a flag? In
particular, what if the two values are Yes/No?