Re: relative complement?

On 18/03/2011 9:15 AM, Erwin wrote:
...
> I looked up "idiosyncracy" in order to understand what is precisely
> meant by that term and found that it seems to refer to "a way of
> thinking (or a way of seeing things, or a way of looking at the world -
> or certain aspects of that world-) that is "peculiar" and "eccentric"
> and "pertains quite individually to the person holding those
> isiosyncratic ideas/points of view/...
> ...

Yes, I meant it that way - most of what I've seen to do with rdbms theory and implementation seems burdened with all kinds of unnecessary baggage which I do find peculiar.

>
>
>> that commonly misleads as well as view updating which
>> I have no problem with, at least conceptually, although I realize that
>> many, many others have big problems with.
>
> The problem(s) you refer to is, I presume, "how to do(/support) it".
> It is -imo quite clearly- a problem for implementers (implementors ?)
> (and possibly for the community of academic researchers researching
> the issue). I fail to see how the set of implementers (UNION the set
> of academic researchers researching the issue) can be described as
> being "many, many others".
> ...

Just my personal exposure. Whenever and wherever I've posted to the effect that I don't see any real problem, the responses were universal that I was wrong, missing some contextual point or other. Maybe 'universal' only amounts to several dozen people given my limited experience but it seems a fair sample of interested people to me.
>
>
>> My own suspicion is that
>> these difficulties are caused mainly by the (again idiosyncratic, also
>> widespread)
>
> Apologies, but how do you match "widespread", with "idiosyncratic",
> given the meaning of the latter term I found in not-really-suspect
> sources ?
> ...

Heh, apologies if my offhand sample would be laughed at in a comp.statistics newsgroup.
>
>
>> tendency to think in terms of target relvars
>
> If you accept the idea that "view updating" is a problem for the
> (DBMS) implementers, how is it possible to NOT think of view updating
> in terms of target relvars ? In fact, target relvars are all there
> really is to the problem. The user targets a non-physically-existing
> relvar (a non-base relvar), the machinery has NOTHING BUT base relvars
> to satisfy the users's request. The implementer has to see to it that
> what he does to the base relvars he has to his avail, will correctly
> reflect the user's request. That's why Date came up with the
> Assignment Principle, which would prohibit, a.o. and e.g., any
> arbitrary insert into A MINUS A.
> ...

I realize that the procedural/imperative implementation camp includes a number of people (just to take your other point, note I didn't say 'many', even though I suspect it's a majority of that camp) who insist on relvars and assignment (or tables and language operators that amount to the same thing AFAICT). Given their chosen languages I don't fault them, it's just that I don't think all possible languages need those concepts, eg., a functional language might depend on side-effects for recording relations. As long as such side-effects don't allow logical inconsistencies it wouldn't bother me. I think Date's Assignment Principle is quite apt for the languages he targets but also that it's probably subsumed by an even more general principle or two, such as not inferring what is not inferable. But such might be so general as to seem not useful to most people.

>
>
> ...
>> and disconnected, abstract notions of insert and delete rather than in terms
>> of asserting and recording both true and untrue statements.
>
> But aren't INSERT/DELETE and ASSERT TRUE/ASSERT FALSE really just
> "appearances in different form" of one and the very same thing ?
>
> If so, how can you be thinking in terms of either, "rather than" in
> terms of the other ?
> ...

I prefer not to have to worry whether they are the same thing or not if that can be safely avoided. My limited intellect finds it easier to dispense with them, at least when trying to discuss theoretical problems. I think the logical aspect of problems (if there are any logical problems) should be dealt with before language problems.

>
>
>> In that sense I can side with McGoveran when he saids "the problem ... goes
>> away"
>
> I can't. The only way in which the "problem" of "finding a unique
> transformation" REALLY goes away, is by declaring it not to be a
> problem.

I've seen you and other smart people write more or less to that effect more than once. But every time I've tried to imagine what the database looks like that they suggest has views that are ambiguous where certain assertions are concerned, I see no ambiguity, just arbitrary biases. I don't fault them for that, especially since my clumsy expression of counter-examples is usually so lengthy that I find it hard to read what I've myself written. Probably what I write is just as hard for them to read as what Date and McGoveran have written is hard for me to read (ie., almost impossible). I think Date and McGoveran are on the right track at least at the point where they start out, but I can't tell if they go off-track at some later point. Eg., I don't know why Date suggests 'deleting from both sides' is 'appropriate' as often as he suggests it is (I quote 'appropriate' because I'm not sure he used exactly that word, in any case I don't think appropriateness comes into it at all - either what I call an assertion and what some call an update is consistent and non-ambiguous or not). Lots of times it seems to me perfectly logical and not ambiguous to 'delete' from only one 'side'. When it comes to what I believe McGoveran means by 'logical independence' I'm a little more confident that he's on the right track because I think it must be accepted that at any given time for some particular purpose, every relation recorded by a dbms should have exactly one set of logically equivalent predicates (otherwise contradictions are possible). But I still can't be certain because I suspect I don't appreciate all the intracacies in what he's written (or what he presumably had written for him, I can't follow his 2007 patent at all).

>
> IMO, that causes problems of its own.
>
> (Well, I should amend that here. The other way that the "problem"
> goes away, is by solving it, of course, as is the case with any
> problem. Such a solution now has become conceivable, methinks, but it
> can be labeled "naive", and is therefore probably still infeasible in
> all but the simplest of settings.)
>
>

 From that point of view, my attitude is probably naive but I would say that is only because I don't know how to optimize for general cases. I don't know how to prove that no practical optimization is possible so I continue to think that I'm not (yet) naive about it! Ie., I don't yet agree with that point of view. I think one could write an engine that naively implemented the equivalent of join deletes and union inserts without inconsistencies and it would be naive only in the sense that it had very ponderous aka slow behaviour.

>
> PS
>
> Do you plan to attend in Newcastle ?

I worked there once, liked the Geordies very much and I thought the night life was much livelier than London's, certainly more concentrated.   I suppose when the ttm experts meet it could be said that the db talent in Newcastle will also be more concentrated than in many, many other places! Much as I'd like to see it again, not having what most people would call income, that seems unlikely. Received on Fri Mar 18 2011 - 22:44:18 CET