Relational Completeness: not just about choice of operators
Quote from Hugh on June 28, 2019, 12:13 pm
[...] SUMMARIZE, but I find that operator far too useful, in both its PER and BY versions [...].
It has always been a mystery to me how anyone can "see" the right SUMMARIZE ... BY ... PER ... to write given a particular problem in the case when the PER ... is needed.
Quote from Erwin on June 28, 2019, 2:41 pmQuote from Dave Voorhis on June 28, 2019, 2:17 pmQuote from johnwcowan on June 28, 2019, 2:13 pmI still don't understand !! at all.
For a long while, I didn't either. Then I implemented it in Rel -- which was oddly easy; it fell naturally out of the relevant mechanisms -- and it became a little clearer.
I still find it painfully counterintuitive.
The basic idea is intuitive enough as it goes, but :
It's slightly unclear to me that using it extensively makes for clearer code,
Agreed. The concept is simply one of a grouping operation on a one-to-many join. We discussed it extensively some time back, and could find no compelling reason to use it in this form.
I believe that every example given in DBE can be mechanically transformed into an equivalent where the target relation is first extended by an RVA attribute with the grouped values. That attribute replaces the !! inside the WHERE clause (or whatever). This is simple and natural to do in Andl. I can't speak for Rel, but would expect no less. The !! syntax adds nothing but obscurity in my reading.
And it's much less slightly unclear to me whether the optimizer that is able to tackle all the intrinsically possible access/computation strategy pitfalls, is a feasible one. (Date has always had this tendency to willingly ignore aspects of feasibility of compiler-level code.)
There is little or nothing for the compiler to do either way, but generate correct code. The SQL query optimiser kicks in to choose between query plans when data statistics are known, and we mostly don't get into that.
Quote from Erwin on June 28, 2019, 2:51 pmQuote from Hugh on June 28, 2019, 12:13 pm
[...] SUMMARIZE, but I find that operator far too useful, in both its PER and BY versions [...].
It has always been a mystery to me how anyone can "see" the right SUMMARIZE ... BY ... PER ... to write given a particular problem in the case when the PER ... is needed.
C If Wordpress supported voting on posts, I'd put a thumbs-up on that one.
Pace Hugh's comment, it's not that what it delivers is not useful; it's that I can never remember exactly which way round to deliver it. Whereas with GROUP and join to RVAs I can both get finer control and see what I'm doing. (I guess SUMMARIZE for tutorial purposes avoids RVAs.)
Quote from Erwin on June 28, 2019, 2:41 pmQuote from Dave Voorhis on June 28, 2019, 2:17 pmQuote from johnwcowan on June 28, 2019, 2:13 pmI still don't understand !! at all.
For a long while, I didn't either. Then I implemented it in Rel -- which was oddly easy; it fell naturally out of the relevant mechanisms -- and it became a little clearer.
I still find it painfully counterintuitive.
The basic idea is intuitive enough as it goes, but :
It's slightly unclear to me that using it extensively makes for clearer code,
Thumbs-up to both Dave's and Erwin's comments. There's some good material in DBE Ch 14. Unfortunately it's smothered by a lot of Date's 'stopping to pick the daisies'. What there isn't is a justification for the power-to-weight of operator !!. Again, I prefer to GROUP and apply projections to the RVAs.
I guess I'm temperamentally a Reduced Instruction Set kind of programmer: I'd rather work with a small, powerful, universally-applicable set of operators, to build more complex behaviour; rather than a large vocabulary of ad-hoc operators.