Re: storing survey answers of different data types

From: paul c <>
Date: Fri, 24 Apr 2009 17:31:25 GMT
Message-ID: <NHmIl.23958$Db2.6118_at_edtnps83>

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. Received on Fri Apr 24 2009 - 19:31:25 CEST

Original text of this message