Re: Updatable views

Rick Elbers wrote:
> Hello Paul,
>
>
> To make it less abstract lets take 1 simple example.
>
> Lets say we have
> Orders, Products, Customers, ProductPrices and OrderDetails and
> we find some way to edit or select all those in 1 gui( thats a
> challenge on itself but a different one). Think about a grid with
> a lot of comboboxes with dropdown style set( so that we can
> add to the combobox too). Now what would be the requirement
> of an updatableView ?
>
> It must have the intelligence to determine from the view schema and
> any possible combination of insert/delete/update( which you cant see
> yet in the gui, but its there believe me)the sequence of actions to
> take against any database tables and execute those too.
>
> My question was and is: can somebody prove that this can't be done
> in general or can't be done in certain circumstances ?
>
> Hope this helps the discussion,
>
> Rick
>

Thanks, I think I get the question now (it seems it doesn't involve recursion) and I think it's a really good one but also a really big one that has at least several aspects to it, none of which have been solved very well by the big-name products.

On the question of view updating in general, there is a debate about it and I've fallen flat on my face elsewhere trying to show that insert to a union is logically sound. On the other hand, it seems there is no real problem with delete from a union. Analogously, insert to join seems logically safe but not delete - this seems to be de Morgan's law at work. Still, when a user inserts to one of the above tables/relations, they are hardly expecting a classical union logical operation, so I think it would be reasonable for the mentioned tables to be displayed from a view of their logical union that excluded all the logical complement tuples. (By the way, when I say 'union', I'm not using it in the usual 'compatible headings' way.)

Having some kind of "seamless" (if that word makes sense here) gui for the "orders, products,...et al" seems an important one to me but at the moment I don't have a lot to say that would be useful to anybody else, ie. that would be of any use with current products. I know very little about it but I believe Microsoft's 'recordsets' were an attempt to achieve some kind of seamless 'flow-through'. However, I believe the recordset approach doesn't go far enough to avoid all the nitty-gritty gui manipulation which may be why I remember people complaining about it years ago. Suffice it to say that I don't see a way through what you are talking about unless there is some kind of 'like' db engine close to the display, as well as at least one other somewhere else - for me, this is the more basic problem with the recordset notion. Even deeper, there seems to be a basic disconnect between what the strict RM interpreters see as the province of the relational operators (see "Load" in TTM) and a procedural 'front-end'.

I think I'd better stop now as I'm probably starting to sound like Celko.

p Received on Thu Dec 08 2005 - 21:32:56 CET