Re: On view updating

Paul wrote:

> ... Suppose I have a database that store employee details and has the
> classic "emp" table. Now a new employee needs to be added. I ask someone
> what his name is and I'm told: "It's definitely either Bill or John, but
> I can't remember which." (a bit contrived but still...)
>
> Now that is a very real fact that I might want to add to my database,
> but (at least with the current design) I can't. I need to know
> definitely whether the name is Bill or John.
>
> I guess I could design the database differently so employee names are in
> a separate "PossibleNames" table (with most employees having only one
> entry here). But this wouldn't cover the general case; I'd have to have
> separate tables for each column! And what about more complex boolean
> expressions?

I don't see a database. I see no facts. I don't see what you are getting at. I would really need some more context. I would appreciate if you would give that, because maybe you *are* on to something interesting. You just did not give enough to go on (for me, that is, maybe others can chime in).

Are you are investigating uncertainty?
What I do see is that you want to store values like: "It's definitely either Bill or John".

Regexes may help.
A regular expression /[Bill|John]/ means "either Bill or John", But even "It's Bill" would just be part of a fact. What does "It's" refer to? Not to an employee, maybe to a 'possible employee' Maybe you can expand a little on the example, focus on what you are looking for - I don't mind if it's contrived.

> ... Suppose we create a row (with empid=234 say) in the emp
> table for this Bill/John, but leave the name part
> blank (empty string). Now we can create a row
> constraint that says:
>
> empid!=234 OR (empid=234 AND (name='Bill' OR name='John' OR name=''))
>
> The interpretation of a empty string can be that the name is not
> precisely known.
>
> But still I've stored information in the database to say that this
> employee is either called Bill or John. It's just not very easy to
> extract this information via a query without going to the system catalog
> and parsing some complex boolean expression.
>
> If I ran a query to tell me how many employees I have that are either
> called John or Bill, it would miss this one. The crux of the problem is
> that the database can't understand the interpretation of the empty
> string in the context of the "employee names" type.

Not so strange, because you just imagined that interpretation, but did not tell the hypothetical database engine.

>>> ...I think of the predicate and you of each individual proposition?
>>
>> Could you elaborate, please?

Ok, Thank you.
I just asked because sometimes people assume "predicate" to mean the internal, strictly formal predicate, other times (like here) the external predicate (how to interpret a row in some table) is meant. Received on Sun Sep 26 2004 - 19:29:34 CEST