There are cases where a lot of data has to be got in quickly - for exqample I might have some measuring equipment that is giving me large numbers (say 10s of 1000s) of readings (each reading is 10s of 16 bit numbers) per second. Then the sensible way to do it isn't to pass the data as parameters to a stored procedure, but to stage them through files and pass a filename for each call of the stored procedure - a proc call per reading would require crazy (currently unavailable) performance levels, and the data isn't algorithmically generated by some known algorithm, it's empirical, so generating it inside the database from a small subset (as in the cases Jeff referred to) is not possible.

These sort of data input rates turn up regularly in radio astronomy, but until fairly recently no-one dreamed of trying to store the data in a relational database (purpose built data handling software written for example in Forth was the order of the day). I think probably anyone looking at SQL to do it even now is probably looking at the wrong tool (so I agree with Jeff and Elliot), but in future I hope that SQL will be able to handle this sort of challenge and think we should be looking at how, with current facilities, it could be approached in SQL.