Re: On view updating

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Wed, 29 Sep 2004 00:43:50 +0200
Message-ID: <4159e928$0$42417$e4fe514c@news.xs4all.nl>

Laconic2 wrote:

[snip monads (???) ]

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

It looks like 'data' maps to first-order logic, and 'process' maps to 'higher-order logic'.

> 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.

But the design *is* capable of reflecting the example fact.

>>   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.

Why is that?

Your example (in another post) of the partial license plate convincingly shows the relevance. Received on Tue Sep 28 2004 - 17:43:50 CDT