Re: On view updating

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.

Why is that?

Your example (in another post) of the partial license plate convincingly shows the relevance. Received on Wed Sep 29 2004 - 00:43:50 CEST