Re: On view updating

mAsterdam wrote:
>> In one case you would have a table constraint like:
>> EXISTS( SELECT * FROM emp WHERE id IN (2,3))
>> In the other case you would have a row constraint like:
>> id IN (2,3)
>>
>> Am I thinking of the former and you of the latter?
>
> I was thinking of the latter.

And I the former.

Ok this is how I see the problem, I think the "X=" syntax is confusing things:

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?

What you're saying, if I understand it, is something like:

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.

>> just thought about this some more, and I realise now that
>> the database can only contain these constraints "X=2 OR X=3"
>> if one or the other of the statements is explicitly contained
>> within the database. Because anything not in the database is assumed
>> to be false.

>
> needs an interpretation along the lines of the former.

yes.

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

nothing profound really, just that the predicate corresponds to the table-level, and a proposition corresponds to the row-level.

predicate: "Employee I is called X"
proposition: "Employee 234 is called Bill"

Paul. Received on Sun Sep 26 2004 - 18:11:13 CEST