Re: Relation Schemata vs. Relation Variables

"Marshall" <marshall.spight_at_gmail.com> wrote in message news:1156136457.048763.114900_at_74g2000cwt.googlegroups.com...
> Brian Selzer wrote:
>> "Marshall" <marshall.spight_at_gmail.com> wrote in message
>>
>> Is the cross product of a set of attributes any less superginormous?
>> Yet,
>> that is how relations are defined. How about the set of consistent
>> database
>> states? I find this argument less then compelling.
>
> Argument?! I was agreeing with you. You said "more than one"
> and I pointed out that the number was actually always very large.
> The two positions are consistent. What were you imagining this
> was an argument of? Never mind; I don't actually want to know.
>

Sorry about that. I misinterpreted your statement.

> It is pretty clear to me that you fundamentally misunderstand
> some of the basics of the RM. It is also pretty clear that you
> are convinced that you do understand them. Have you noticed
> yet that *no one* buys your argument about people changing
> their names? Nobody. You bring us the same example again
> and again, you defend it with detailed explanations and what
> you probably think of as well-reasoned logic, and yet we're
> all unmoved. So which is more likely: you understand and
> everyone else everywhere gets it wrong, or that you have
> a basic misunderstanding?
>

I was just trying to be concise. If you can't see that it can happen from this simple example, then how would you possibly be able to see that it can happen in much more complicated and subtle situations. It is extremely difficult not only to articulate the circumstances surrounding the numerous instances where I've seen similar situations, but also to defend the bozos that designed the systems in the first place along with the people who wanted to change the keys. Most of the work I do is cleaning up the messes that others have made. One situation involved a poorly-written trigger that, in part, prevented an inventory row from being deleted unless the quantity on hand was zero. Since the trigger was defined as FOR UPDATE, DELETE, it rejected key updates if any affected row had quantity because it could not correlate the rows in the deleted pseudotable with those in the inserted pseudotable, and thus it appeared that those rows were being deleted. The symptoms in this case involved an update being interpreted as a delete, but the underlying problem is the same: the inability to correlate tuples during an update in the presence of a transition constraint where the key can change.

So, yes, I do understand. I wouldn't say that everyone else everywhere gets it wrong, but instead that because of the work that I do, my experience with unusual situations is broader than most.

>
> Marshall
>
Received on Mon Aug 21 2006 - 08:42:53 CEST