Self partitioning a relation
Quote from Greg Klisch on April 1, 2020, 5:02 pmJust a thought: does anyone see any value to partitioning a relation over a projection of itself? For example [maybe not a good example]:
Get suppliers with fewer than three shipments.
SP {S#} WHERE COUNT ( ‼SP ) < 3
Just a thought: does anyone see any value to partitioning a relation over a projection of itself? For example [maybe not a good example]:
Get suppliers with fewer than three shipments.
SP {S#} WHERE COUNT ( ‼SP ) < 3
Quote from Erwin on April 1, 2020, 7:15 pmQuote from Greg Klisch on April 1, 2020, 5:02 pmJust a thought: does anyone see any value to partitioning a relation over a projection of itself? For example [maybe not a good example]:
Get suppliers with fewer than three shipments.
SP {S#} WHERE COUNT ( ‼SP ) < 3
Well, if it provides the correct answer to your question then that is the value, isn't it ?
Quote from Greg Klisch on April 1, 2020, 5:02 pmJust a thought: does anyone see any value to partitioning a relation over a projection of itself? For example [maybe not a good example]:
Get suppliers with fewer than three shipments.
SP {S#} WHERE COUNT ( ‼SP ) < 3
Well, if it provides the correct answer to your question then that is the value, isn't it ?
Quote from Dave Voorhis on April 1, 2020, 7:28 pmQuote from Greg Klisch on April 1, 2020, 5:02 pmJust a thought: does anyone see any value to partitioning a relation over a projection of itself? For example [maybe not a good example]:
Get suppliers with fewer than three shipments.
SP {S#} WHERE COUNT ( ‼SP ) < 3
Looks like a good example to me.
If you find the query readable and it generates the results you expect under all cases, then it's of value.
Quote from Greg Klisch on April 1, 2020, 5:02 pmJust a thought: does anyone see any value to partitioning a relation over a projection of itself? For example [maybe not a good example]:
Get suppliers with fewer than three shipments.
SP {S#} WHERE COUNT ( ‼SP ) < 3
Looks like a good example to me.
If you find the query readable and it generates the results you expect under all cases, then it's of value.
Quote from AntC on April 1, 2020, 10:33 pmQuote from Greg Klisch on April 1, 2020, 5:02 pmJust a thought: does anyone see any value to partitioning a relation over a projection of itself? For example [maybe not a good example]:
Get suppliers with fewer than three shipments.
SP {S#} WHERE COUNT ( SP ) < 3
There was a long and meandering thread about Date's IMAGE operator
!!
. My take is that some shorthands around 'partitioning a relation over a projection of itself' would be useful, but that!!
is not the most useful of those. That partitioning is exactly what theGROUP
operator does.
SP_PART := SP GROUP { P#_QTY := {ALL BUT {S#}}}
// might have got the syntax wrong
SP_PART EXTEND : { PQ_COUNT := COUNT(P#_QTY); Q_SUM := SUM(QTY FROM P#_QTY)} WHERE PQ_COUNT < 3
Most of the examples for
DIVIDE
and friends focus on 'Suppliers that supply all parts' so need mention of two or more relvars. But I find it easier to think ofGROUP
each relvar individually to give RVAs then JOIN on the RVAs. Exactly you're partitioning each relvar over a projection of itself. (That's another reason I don't waste mental energy onDIVIDE
.)
Quote from Greg Klisch on April 1, 2020, 5:02 pmJust a thought: does anyone see any value to partitioning a relation over a projection of itself? For example [maybe not a good example]:
Get suppliers with fewer than three shipments.
SP {S#} WHERE COUNT ( SP ) < 3
There was a long and meandering thread about Date's IMAGE operator !!
. My take is that some shorthands around 'partitioning a relation over a projection of itself' would be useful, but that !!
is not the most useful of those. That partitioning is exactly what the GROUP
operator does.
SP_PART := SP GROUP { P#_QTY := {ALL BUT {S#}}}
// might have got the syntax wrong
SP_PART EXTEND : { PQ_COUNT := COUNT(P#_QTY); Q_SUM := SUM(QTY FROM P#_QTY)} WHERE PQ_COUNT < 3
Most of the examples for DIVIDE
and friends focus on 'Suppliers that supply all parts' so need mention of two or more relvars. But I find it easier to think of GROUP
each relvar individually to give RVAs then JOIN on the RVAs. Exactly you're partitioning each relvar over a projection of itself. (That's another reason I don't waste mental energy on DIVIDE
.)