One thing that you have to remember is that FoxPro will always index some fields, while MySQL
will only ever index the primary key field automatically.
Indexes can be on fields that are distinct or not distinct. The only difference that exists is
the nature of the index, which is one of those details the RDBMS handles by itself.
VFP has Rushmore, which does a bunch of funky things. At the moment (and the MySQL
docs currently agree with me on this), MySQL only has one real weakness - it's optimiser.
If you consider this fact (Oracle's optimiser is really it's greatest strength for example), the
speed of MySQL is even greater an achievement. The great Monty himself names the
optimiser as amongst the hardest things to get right for an RDBMS. It's not to say that
the optimiser is bad, it's just to say that MySQL AB have quite a few things planned for
improvement in that particular area.
Regards,
Chris
Héctor Villafuerte D. wrote:
Chris Nolan wrote:
Hi!
Given VFP's internals (I have to support FoxPro 2.6 apps, oh the pain of it all!),
MySQL should be capable of much better performance, considering the
only thing FoxPro has in terms of a possible advantage is Rushmore.
Which indexes do you have on the tables in the query?
Regards,
Chris
Indexes? hmmm... I knew those were useful for something :)
In Visual FoxPro I don't use indexes for this table... so I didn't considered them
necessary in MySQL (now I think I need to get to the basics of RDBMS).
This table I'm talking about is a CDR (call detail record), so a record represents
a call from a given telephone. I'm surely wrong but, ain't the index suppossed to be
on a field with distinct entries?
Does VFP automagically creates indexes depending on the query?
As you can see, I would greatly appreciate any pointers to some database theory.
Thanks again!
Hector
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
