chap file processing and external sorting of single bank of read/write heads that move together over stack of platters if the sorting process involves reading from an input filealternated with writing to an output filethen the / head will continuously seek between the input file and the output file similarlyif two input files are being processed simultaneously (such as during merge process)then the / head will continuously seek between these two files the moral is thatwith single disk drivethere often is no such thing as efficient sequential processing of data file thusa sorting algorithm might be more efficient if it performs smaller number of non-sequential disk operations rather than larger number of logically sequential disk operations that require large number of seeks in practice as mentioned previouslythe record size might be quite large compared to the size of the key for examplepayroll entries for large business might each store hundreds of bytes of information including the nameidaddressand job title for each employee the sort key might be the id numberrequiring only few bytes the simplest sorting algorithm might be to process such records as wholereading the entire record whenever it is processed howeverthis will greatly increase the amount of / requiredbecause only relatively few records will fit into single disk block another alternative is to do key sort under this methodthe keys are all read and stored together in an index filewhere each key is stored along with pointer indicating the position of the corresponding record in the original data file the key and pointer combination should be substantially smaller than the size of the original recordthusthe index file will be much smaller than the complete data file the index file will then be sortedrequiring much less / because the index records are smaller than the complete records once the index file is sortedit is possible to reorder the records in the original database file this is typically not done for two reasons firstreading the records in sorted order from the record file requires random access for each record this can take substantial amount of time and is only of value if the complete collection of records needs to be viewed or processed in sorted order (as opposed to search for selected recordsseconddatabase systems typically allow searches to be done on multiple keys for exampletoday' processing might be done in order of id numbers tomorrowthe boss might want information sorted by salary thusthere might be no single "sortedorder for the full record insteadmultiple index files are often maintainedone for each sort key these ideas are explored further in