On Wed, Aug 13, 2014 at 11:45 AM, Roy Smith <r...@panix.com> wrote: > In article <mailman.12903.1407893523.18130.python-l...@python.org>, > Chris Angelico <ros...@gmail.com> wrote: > >> I like to look at SQL as a language that specifies an end result >> without specifying how to get there > > Well, sure, but sometimes the how to get there is a matter of 10x, or > 100x, or 1000x in performance.
Of course it can! But generally, the "how to get there" is not stipulated in the SQL statement. If you say, for instance: select * from some_table where some_column='some_value'; then an index on some_column will make a huge difference to performance - without changing this statement at all. In contrast, taking advantage of an index in BTrieve requires recoding your program, as the index used is a part of the API call. (At least, this is true of the particular version of BTrieve that back-ended our accounting package in the 90s. I was able to turn an overnight job into a thirty-second job by rewriting it as an external program; the original is closed-source so I can't be sure, but I suspect most of that improvement is simply because I used an index.) SQL itself doesn't even have provision for indexes. The 'CREATE INDEX' command, found in many databases, is an extension. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
