>>I think you got it backwards. Databases should record simple facts from which *answers* can be constructed for questions. <<

I do like that better!

>> If "Yes/No" is an answer to some question, the DBMS must allow for it be recorded so that other questions can be answered. It is closure, remember? <<

With that model, a database would already have **all** possible
answers in it before all possible questions are asked. Not possible
even in theory. And the answers are at a different level than the
facts -- the old data and meta data getting mixed together problem,
the need to constantly update the flags when the underlying facts
changes, etc.

Closure in a mathematical system assures that you can compute an
answer from facts, rules, axioms, etc. when presented with a
question.

> the need to constantly update the flags when the underlying facts
> changes,

When the flag itself is the fact, this makes very little sense.

>> With that model, a database would already have **all** possible answers
>> in it before all possible questions are asked.

Not all possible answers, but a provision to record any possible answer.

A DBMS derives new facts (query results) from a set of asserted facts (the
database). If the initial assertions are true and derivation rules are
consistent the derived facts are true (i.e. query results are correct).

Therefore as a deductive logic system, when required the DBMS must allow for
the derived facts to be recorded as needed, not that it should record all
possible derivations.

We already do this all the time using views, derived tables, CTEs etc.

>> And the answers are at a different level than the facts -- the old data
>> and meta data getting mixed together problem, the need to constantly
>> update the flags when the underlying facts changes, etc.

Conceptually the answers themselves are facts if the inference rules are
sound. It is we who assume a distinction due to limitations in our tools,
methods and languages.

Yes, the term "flag" carries certain baggage from CS history, but I fail to
see an argument to avoid a domain with two values, in general.

--
Anith

>> Yes, the term "flag" carries certain baggage from CS history, but I fail to see an argument to avoid a domain with two values, in general. <<

If it is really a domain, I have no problem. I might have problems
with a domain that has only one value, tho. The problem is that a
flag is a computation, predicate, etc. that needs to be derived over
and over from other values. To describe a box, would you store
(length, width, height) then add a column for volume? Of course not
-- it is redundant. Volume by itself would also hide information
about the three variables that went into computing it.

> with a domain that has only one value, tho. The problem is that a
> flag is a computation, predicate, etc. that needs to be derived over
> and over from other values.

A yes/no question does not have to derived / computed / etc. Do you like
lemonade? Yes. Or no. Maybe your answer changes over time. But it does
not depend on any other values whatsoever.

> To describe a box, would you store
> (length, width, height) then add a column for volume? Of course not
> -- it is redundant. Volume by itself would also hide information
> about the three variables that went into computing it.

We're not even talking about the same thing here. You are blindly grasping
for an example of something that IS computed and clearly IS NOT what anyone
in their right mind would consider a "flag"... play fair and honest, celko!

> We're not even talking about the same thing here. You are blindly
> grasping for an example of something that IS computed and clearly IS NOT
> what anyone in their right mind would consider a "flag"... play fair and
> honest, celko!

create table celko_answer_clutching (
forum_nntp_guid uniqueidentifier not null primary key,

post_author varchar(200) not null,

is_straw char(1) not null check( is_straw = 'Y' or ( post_author <>
'--celko--' and is_straw in ( 'Y', 'N' ) ) ) )
)



--
Tony Rogerson, SQL Server MVP
http://sqlblogcasts.com/blogs/tonyrogerson
[Ramblings from the field from a SQL consultant]
http://sqlserverfaq.com
[UK SQL User Community]


"Aaron Bertrand [SQL Server MVP]" <ten.xoc@dnartreb.noraa> wrote in message
news:23520CDC-93AE-4DBF-A2B7-D3E321CFD32B@microsoft.com...
>> with a domain that has only one value, tho. The problem is that a
>> flag is a computation, predicate, etc. that needs to be derived over
>> and over from other values.
>
> A yes/no question does not have to derived / computed / etc. Do you like
> lemonade? Yes. Or no. Maybe your answer changes over time. But it does
> not depend on any other values whatsoever.
>
>> To describe a box, would you store
>> (length, width, height) then add a column for volume? Of course not
>> -- it is redundant. Volume by itself would also hide information
>> about the three variables that went into computing it.
>
> We're not even talking about the same thing here. You are blindly
> grasping for an example of something that IS computed and clearly IS NOT
> what anyone in their right mind would consider a "flag"... play fair and
> honest, celko!

>> A yes/no question does not have to derived / computed / etc. Do you like lemonade? Yes. Or no. Maybe your answer changes over time. But it does not depend on any other values whatsoever. <<

But that preference is a value:

CREATE TABLE Foobar
(..
beverage_choice VARCHAR(15) DEFAULT 'water' NOT NULL
CHECK (beverage_choice IN ('lemonade', 'beer', etc.)),

Surely, you would not ask "Do you live in Texas?" "Do you live in
California?" etc. for all 54 states and territories? And don't forget
a constirant to assure that only one of the 54 flags is set to 1.

>> You are blindly grasping for an example of something that IS computed and clearly IS NOT what anyone in their right mind would consider a "flag". <<

I defined a flag as bit that is set to mark an event or set of
conditions (think of Dijkstra's semaphores and other low-level
assembly language tricks). But the event or conditions do not have to
be the agent that sets the flag. Nor does a domain with only two
values have to be a flag. In RDBMS, we want to have the set of
conditions, so we can compute the answer to the question with a search
condition:

SELECT guest_name
FROM Invitations
WHERE beverage_choice = 'lemonade';

Do you see the difference?

> But that preference is a value:
>
> CREATE TABLE Foobar
> (..
> beverage_choice VARCHAR(15) DEFAULT 'water' NOT NULL
> CHECK (beverage_choice IN ('lemonade', 'beer', etc.)),

Why? What if the company is Country Time and all they care about is
lemonade?

> Surely, you would not ask "Do you live in Texas?" "Do you live in
> California?" etc. for all 54 states and territories?

No, but if I was a company that could only sell to people in Texas, I might
ask "Do you live in Texas?" exactly once. If you live in some other state,
survey over.

> I defined a flag as bit that is set to mark an event or set of
> conditions (think of Dijkstra's semaphores and other low-level
> assembly language tricks). But the event or conditions do not have to
> be the agent that sets the flag.

But often the condition IS the flag, Joe! Let's say I have a table that
represents a set of servers in my network. At any single point in time, I
run a process that must determine which of the servers are labeled as
"Active"... why is it so wrong to have a column called IsActive or Active,
with the possible values of Y or N? Consider that I don't care about the
history, when it became the current state, etc. I just want to know which
servers are active right now. Sorry, but this is the way I would model it.
You can design it your own way if you want.

> Do you see the difference?

I see the difference, but you either don't understand my point, or are
intentionally ignoring it.