Re: storing survey answers of different data types

On Apr 24, 10:31 am, paul c <toledobythe..._at_oohay.ac> wrote:
> Marshall wrote:
> > On Apr 24, 7:48 am, Bob Badour <bbad..._at_pei.sympatico.ca> 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.

I don't think what you're saying poses any particular problem.

Theses days, if I have a property (such as the ones you mention) that I'd like to have, I tend to want to look for a formalization in which said property is a provable consequence. So in this case, assuming I adopt you desired goal, I'd see (once, you know, I actually have something to look at) whether it couldn't be proven that my approach always upholds the property you mention.

Formalizing the imperative operators isn't particularly hard, at least not for insert and delete. And I have some crazy ideas for update that I'll be pursuing when the time comes.

Marshall Received on Sun Apr 26 2009 - 20:40:21 CEST