glassmann@ccavax.camb.com (02/07/90)
I'm new at this, so this may have been discussed already, but...
Is dBASE IV SQL incredibly slow? I created a small table and did a
SELECT WHERE, and it took about 8 seconds, with lots of disk accesses.
The equivalent query in normal dBASE took under a second.
--
Lenny Glassmann lenny@ccavax.camb.com
...uunet!ccavax!lennyawd@dbase.A-T.COM (Alastair Dallas) (02/09/90)
In article <16946.25cffdfa@ccavax.camb.com>, glassmann@ccavax.camb.com writes: > I'm new at this, so this may have been discussed already, but... > Is dBASE IV SQL incredibly slow? I created a small table and did a > SELECT WHERE, and it took about 8 seconds, with lots of disk accesses. > The equivalent query in normal dBASE took under a second. > -- > Lenny Glassmann lenny@ccavax.camb.com > ...uunet!ccavax!lenny I don't recall this being discussed. Terms like 'slow' and 'fast' are relative, you see. If a painter wants to show a bright light, he paints with black. Most PC SQL implementations that I've seen (which is not all that many) do things in a mainframe mode and write lots of temp files which makes them slower than a native program like dBASE. This entire mail is a little tongue-in-cheek, but I have heard others say that dBASE/SQL is particularly useful as an introduction to SQL for dBASE users and that in this context, speed is not much of an issue. I certainly haven't heard that from any official Ashton-Tate sources, however, and neither have you. /alastair/
cy@dbase.A-T.COM (Cy Shuster) (02/09/90)
In article <419@dbase.A-T.COM> awd@dbase.A-T.COM (Alastair Dallas) writes: >In article <16946.25cffdfa@ccavax.camb.com>, glassmann@ccavax.camb.com writes: >> I'm new at this, so this may have been discussed already, but... >> Is dBASE IV SQL incredibly slow? I created a small table and did a >> SELECT WHERE, and it took about 8 seconds, with lots of disk accesses. >> The equivalent query in normal dBASE took under a second. [lines omitted] >... but I have heard others say that dBASE/SQL >is particularly useful as an introduction to SQL for dBASE users and that >in this context, speed is not much of an issue... I agree: it's useful to note that the objective was to provide SQL support, and as you might expect in any first release, its performance is not as good as dBASE. However, I know that there's a certain fixed amount of overhead in using SQL, so that the case you tried is, perhaps, a worst case. I haven't measured it, but I expect that queries run on larger tables would start to more closely match dBASE native speed. --Cy-- cy@dbase.a-t.com Disclaimer: My opinions only.