|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |