> modeling of the whole database
Doesn't seem like it's hard to do.
With MD arrays, you are all but there anyway:
Table:
A 2d array.
Whatever is introduced to more directly support
handling MD arrays could very plausibly help in
more directly supporting handling of single table
data. This includes basic syntax, and standardized
MD array sorting, filtering, and aggregating functions
(which will all but inevitably emerge once standard
direct support for MD arrays is in place).
"Virtual dataset" from one table:
A 2d 'slice' or rectangle. Both slices must support,
er, discontiguousness.
'Horizontal' slice picks certain fields from the set
available. I would expect it to be a small (or zero)
hop, from whatever MD array syntax Perl 6 ends
up with, to having a slice serve as a field selector.
'Vertical' slice picks certain records based on
column data. This will be a bigger hop, involving
some array filtering function, but it again seems
inevitable that Perl 6's MD arrays will have this
sort of filtering function/feature available. So,
again, possibly zero extra work required.
Dataset from multiple 'joined' tables
(A pair of joined tables can be visualized as two
spreadsheet like grids that intersect at right angles
with the intersection point being the joined column.
The vertical slice picks out rows where the joined
column values from the two tables are the same.)
Whatever is used to support vertical slicing based
on col data should be extensible to do joining too.
With the above, you have all the direct support I need to do
all the non-transactional database crunching I have done
with perl for the last several years. ALL of it. I'm pretty sure
I'd be able to do grand sweeping db operations in one liners!
> <DejaVu>Didn't we have this discussion about six months ago???</>
I searched the perl6-all archives for any discussion
of this sort of stuff when I first started to think about it.
I used the string "SQL". I read all the posts (about 50-100 iirc).
None went down this path.
