Re: On view updating

"Paul" <paul_at_test.com> wrote in message news:41595cde$0$69737$ed2619ec_at_ptn-nntp-reader01.plus.net...

> Taking this to its logical absurdity, you could have a table with a
> single column of type "logical proposition"! With a function "VAL" say
> that returned either true or false.
>
Excuse me, but isn't this where the binary number system intersects with Emmanuel Kant's "monads"?

It's logical, but I'm not sure it's absurd. Unworkable, yes, but absurd, no. But I could be wrong. some of this theoretical stuff is out of my league.

> It also means the DBMS has to be know this type is a regular expression,
> just as it had to know an empty string meant "missing data". Because
> suppose you enter a value of '/[Bill|John]/' for someone's name. Now if
> you do a query in SQL like:

Lestrade: "Is there anything to which you wish to draw my attention?" Holmes: "To the curious incident of the dog in the night." Lestrade: "The dog did nothing in the night." Holmes: "That was the curious incident."

I'm designing some stuff in my spare time, and I find it really important to distinguish between "missing" and "empty".

Oracle, unfortunately doesn't do that in the case of VARCHAR.

>
> SELECT * FROM emp WHERE name = 'Bill' OR name = 'John'
>
> It's not going to pick up our row, even though logically it should.
> You'd have to just know that the column is a regular expression and use
> some function called "Like" say that takes two regexps as arguments and
> returns true if the first regexp is a subset of the second.
>

Maybe the solution lies in expressing the partial info as data, rather than as process.

Let's say I have a table with a binary relation, EMPLOYEE_ID and FIRST_NAME. Further, let's say no nulls, no duplicates. Now let's say we have,
EMPLOYEE_ID: 12345, FIRST_NAME: 'John'
EMPLOYEE_ID: 12345, FIRST_NAME: 'Bill'

in this relation. The assertion is
"The employee with ID: 12345 might have first name 'John'." "The employee with ID: 12345 might have first name 'Bill'."

Most employees only have one tuple in this relation. (I know, it's grotesquely inefficient. Don't try this at home.) A few employees have multiple entries. Afew employees have no entry, even though they have an employee id. This means that their First name is "known to be missing".

Now the query is a simple one. The OR has been subsumed by the fact that we can join with one row or the other.

Just playing around. I know this won't work for more complex patterns.

> SELECT * FROM emp WHERE Like(name, '/[Bill|John]/') = 1
>
> The "Like" function would have to realise that, for example,
> '/[Bill|John]/' and '/[John|Bill]/' meant the same thing. Also you'd
> want Like('/[Bill|John]/', '/[Bill|John|Fred]/') to be true.

OK, what follows is real "skunk works". I've done it, but I'm not proud.

SELECT emp.* FROM emp, name_patterns
WHERE emp.fname LIKE name_patterns.fname AND ...

Now, if name_patterns.fname is 'Joh%', we'll get a match on either 'John' or 'Johannes'.

This is stretching the model beyond what is reasonable. Received on Tue Sep 28 2004 - 16:34:54 CEST