Re: storing survey answers of different data types

From: Bob Badour <>
Date: Fri, 24 Apr 2009 16:53:11 -0300
Message-ID: <49f218a9$0$5476$>

paul c wrote:

> Marshall wrote:

>> On Apr 24, 7:48 am, Bob Badour <> wrote:
>>> lawpoop wrote:
>>>> But if you decide that the view updating problem means that Codd's
>>>> model is broken, therefore should be abandoned, what are you going to
>>>> replace it with?
>>> Vadim and Marshall have looked very hard at lattices and that shows some
>>> promise.
>> Hello? Hello? Did someone say my name? Is this mic on?<tap tap tap>
>> Hi everybody!
>> It's not so much that anything of Codd's is broken as it is the case
>> that the regular relational algebra is rather ... misshapen. It's
>> doesn't even meet the technical criteria to be an algebra, unless
>> you want to say it's a many sorted algebra with a different
>> sort for each of the various things that can be used as
>> parameters to the operations: sets-of-columns for project,
>> predicates for select, etc. I think this degree of irregularity
>> has really hampered the development of the theory.
>> That's why I'm so interested in Vadim's algebra; it's a real
>> algebra, it's quite small (only two operators) and clean.
>> Now all we have to do is figure out the complete theory
>> of the thing and we'll be making some progress. So that's
>> what I'm working on this morning. The birth of the twins
>> has really slowed things down though.
>> I had the idea long back that view updating should be
>> looked at in terms of ambiguity. Then later I talked myself
>> out of that, and still later Vadim gave a quite convincing
>> argument that the problem was exactly one of solving
>> equations, and that pretty much brings us back to the
>> question of ambiguity. Lots of folks are of the opinion
>> that you therefore need some way for the view designer
>> to indicate a way to disambiguate. I'm a bit skeptical,
>> but I haven't looked closely at this part yet. (It clearly
>> comes after getting the equation-solving technique right.)
>> Anyway, blah blah blah, nothing really interesting to
>> report still, but I'm working on it.
>> Marshall
> Hi, Marshall, nothing against lattice development, best of luck, but the 
> 'solving equations' approach reminds me of the Microsoft motto I heard 
> somewhere "when all you have is a wrench, every problem looks like a 
> nail!".  Personally, I am quite happy with a notion of 'delete' 
> ('delete' of a row after all not being a notion in any algebra that I 
> know of) that insists that a 'delete' never causes an 'insert' to 
> anything but the logical complement of a relvar, or loosely a table, and 
> possible extensions of algebraic expressions that are inferrable from 
> the complement.. In similar fashion, 'insert" should never 'delete' from 
> anything but the complement and its 'inferrables'.  In other words, the 
> language requirement drives the implementation and doesn't hit a nail 
> with a wrench.

That would pretty much make audit trails impossible. Received on Fri Apr 24 2009 - 21:53:11 CEST

Original text of this message