As this has drifted off-topic, I've set the Reply-To on this to
POOP-group, please send replies there and not perl6-language.
On Sun, Jun 10, 2001 at 06:06:27PM -0500, Me wrote:
> > modeling of the whole database
>
> Doesn't seem like it's hard to do.
HA! Think "Lights Out": It...is...harder...than...you...think!
You may wish to read this thread about lazy arrays and object
persistence to get an idea of what you're getting into.
http://www.geocrawler.com/archives/3/3024/2001/3/0/5427925/
I'm not trying to discourage you (well, maybe I am), just trying to
transplant some hind-sight from me to you.
> Table:
>
> A 2d array.
Rows are refered to by primary keys. Primary keys are often not
numbers. Switch to a hash and you might have a chance.
> 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
If you can map an aribtrary Perl sort function onto SQL and do it
efficiently AND make it work on more than one database, I will be
extremely impressed.
> filtering, and aggregating functions
> (which will all but inevitably emerge once standard
> direct support for MD arrays is in place).
Again, this must all be mapped onto SQL. To do this efficiently is
extremely difficult.
> "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.
Two problems. SQL columns have names, not numbers. Refering to them
by number is a Great Leap Backward. Use a hash.
> 'Vertical' slice picks certain records based on
> column data.
The 23rd row of a table doesn't have much meaning without a sort
order. Even then, its relatively rare to want to pick out the 23rd
row of a SELECT. Typically you just get them in order. Occasionally
you'll want a slice (ie. rows 51-100) but few databases support this
syntax efficiently (MySQL is an exception).
A filehandle would be a closer analogy. In fact, its very close.
Trying to model an SQL table as an array is similar to modeling a file
as an array. For example, $lines = @file; is expensive just as $rows
= @select (assuming there's a WHERE clause involved). $file[42] and
$select[42] are also both expensive. And what do you do with rows
0..41? Throw them out? Hang onto them and eat memory?
> 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.)
That will only work for extremely simple joins.
--
Michael G Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
