Re: By The Dawn's Normal Light

On Fri, 22 Oct 2004 17:38:36 +0100, Paul <paul_at_test.com> wrote:

>SELECT * FROM a WHERE Like(b, 'Z%') = TRUE
>SELECT * FROM x WHERE f(a,1,2) = 5
>
>where Like() and f() are some type operators.

And "=" is another type operator.

>Strictly speaking, I'd say we should also be able to push the equality
>operator into the type engine rather than the relational engine.

The scalar equality operators are not a relational operators.  

>Assuming WHERE clauses would support boolean values. For example, how
>does the relational engine know that 2/4 = 1/2 in the domains of
>rational numbers? It doesn't: it has to ask the type engine.

The same for integers and booleans. "Where" can't exist without scalar operators.

Relational operators are also type operators, relational variables also have a type.

There is not a clear distinction between scalar and not scalar types either.

I remember an old discussion with Bob Badour about this, and now I think that we was right yet another time.

>Certainly, but I'm suggesting there are clear and useful dividing lines
>between the work done by the "type engine" and the work done by the
>"relational engine".

But the relational engine is a superset of the type engine. The relational operators can't exist without the scalar operators.

>At the very extreme end, you could have a database with only one type,
>and only one type operator: the test for equality. Maybe not practically
>useful, but worth thinking about.

But if you have one scalar type and one scalar operator you still have scalar types and scalar operators (1>0). There is not any fundamental difference.

It is a lot better to forget the idea of "atomicity" as an absolute concept.

>> 1NF is superfluous, a relation is always in 1NF
>
>Yes, by the standard definition of "relation" maybe.

Not maybe, definitely! ;-)

> But the original
>message in this thread defined a relation as a table with no duplicate
>rows.

And without nulls!

This was often forgotten in this thread.

> And I guess implicitly a table was defined as a bag/multi-set of
>tuples of the same type.

As a multiset with nulls, and this is not a multiset, this is a shit! like a biology teacher I had would say :-)

>I guess the 1NF requirement that values be atomic is really a
>requirement of the RDBMS itself rather than the table though.

So they are not RDBMSs, they are a ... :-)

Regards Received on Sun Oct 24 2004 - 04:40:05 CEST