Re: storing survey answers of different data types

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:Xg2Jl.24350$Db2.19062_at_edtnps83...
> Brian Selzer wrote:
> ...
>>
>> I disagree: in this case the Delete is unsafe because it might violate a
>> referential constraint (the one-to-many constraint Date refer's to);
>> there is no danger of any Select violating a constraint.
>> ...
>
> You and Date are both wrong. There is no notion of constraint in Codd's
> calculus nor the algebra. Therefore constraints must be applied to the
> results of a desired algebraic operation (this doesn't prevent constraints
> being expressed by the algebra), they cannot be applied as part of an
> algebraic operation like 'minus' or 'union'.
>

Delete is not an algebraic operation. Neither is Insert nor Update. Insert, Update and Delete, or combinations thereof, are assertions, not queries. Date and Darwin hold that they're shortcuts for assignment, and I would argue that it is assignment that is the shortcut, but in neither case are they operations of the algebra.

I think the problem may be that you're equating delete with minus and insert with union. The algebraic expression, A MINUS B, is a query: it does not assert that A has a new value; similarly, the algebraic expression, A UNION B, is also a query: it does not assert that A has a new value.

>> I would also suggest that you apply simple logic:,,,
>
> That is exactly what those who say the problem is undecideable do.

What has decidability to do with it? The result of a select issued yesterday may be completely different from the result of the same select issued today. Similarly, the result of the select before the delete may be completely different from the result of the same select after the delete.

> Simple logic is misplaced unless it recognizes that here we are not only
> talking about mapping to values that produce true propositions via
> prediicate logic. The real situation is that when we update a relvar, we
> are also updating a database.

Yes, updates are database updates, not merely relvar updates. But by applying simple logic, you will recognize that what had up to the update been the case may not still be at or after the update. Therefore, a query issued before and after the update may yield different results.

> 'Simple logic' applied to the actual situation will show that a delete to
> 'one side' of a join will also insert to possible relvars that are not
> inferrable from the join (eg., the value of A MINUS B is non inferrable
> from A JOIN B). Similarly, an insert to 'one side' of a union will delete
> from such non-inferrable relvars.

I'm not sure what you're driving at. If you assert that A has a new value, then what's wrong with A MINUS B having a different value than before the assertion?

> Now, if somebody says such side-effects are a consequence of logic, then
> they will also have to agree that 'Delete ... from R' is logically
> nonsense, specifying 'R' in an implementation language becomes meaningless
> when other non-inferrable relvars might be changed. In fact, the very
> word 'Delete' becomes nonsense when non-inferrable 'inserts' are made.
>
>
> The very suggestion that there is more than one way to 'map' is a mis-use
> of logic. This is why simple logic by itself is not enough. But it can
> help point the way when a database is involved.

I'm not sure I understand what you mean. Received on Mon Apr 27 2009 - 07:34:39 CEST