>> The concept of performing a multi-table join where the tables are all 
>> stored on magnetic tape scares me. o_O
>>
>> My God, it could take months...
> 
> Not at all.  Simply sort the two (or more) files in sequence by the join 
> key (one or more fields).  Then it is a matched scan or 'merge join' 
> through both.  Variants for Inner, Left, Right and Full Outer joins.
> 
> As to sorting large tape files - You already have my reminiscence of 
> 'Real Sort I' on your blog.  Actually that whole thing was equivalent to 
> a join of the account table to the transaction table when both were 
> stored as sequential files on multiple volumes of tape.  Multiple months 
> of Tran had to be merged and sorted into account sequence.
> 
> This was before disk databases and SQL were practical considerations for 
> this application.

Indeed - it sounds like back then, doing this kind of stuff was pushing 
hard against the limits of technical feasibility. Like every individual 
operation had to be planned and hand-tuned and assisted by an army of 
technitions. Seems like having an SQL language would be a bit redundant.

...and yet, SQL is apparently that old. Go figure!

> So that was about 12Gb of disk in total - for a largish bank.  In my 
> pocket I now carry a 16Gb memory stick to backup files and sync across 
> machines.

Damn, they make memory sticks that large now??

> Tapes back then held something like 100Mb per reel (IBM 3420 1200 foot 
> ?) reel.  But there could be thousands of tapes in the library so that 
> was hundreds of Gb.

Amusingly, today I work with LTO3 tapes, which hold 400GB each. So... 
only about a thousand times more. (Not, say, several million.) Then 
again, I think those tapes might be slightly bigger physically too!

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message