Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Is it reasonable to have index on DELETED()?
Message
 
À
21/03/1999 14:19:00
Walter Meester
HoogkarspelPays-Bas
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Divers
Thread ID:
00196021
Message ID:
00200596
Vues:
11
Hi Walter,

>If you look at this from a theorecticly point of view there is NO way that a TAG on delete could benefit performance if there are no deleted records.

But here you are wrong. When you have SET DELETED ON, VFP has to read every record and check the deleted state (that's the first byte in the record). Whether this decreases performance or not, depends on a number of things:

1. How much time does this checking need compared with the time to create a bitmap? Here take into account that a bitmap has only to be generated once, while checking is performed every time.

2. Would VFP have to read all records anyway? If it would read them, there's indeed little performance difference. If not, reading all records decreases speed drastically. It hasn't got to read them when you create a filtered table, or when you issue a command that doesn't process all selected records (for example the grid or BROWSE).

3. How much of the record are you reading. If you are only reading a few fields, VFP might only read that part from the table. If VFP has to check for the deleted state it has to read that part, too. This means that it either reads a huge portion of the record, or the number of requests to the server doubles.

4. Do you issue commands that move the record pointer. LOCATE/CONTINUE for example. If you have an index on DELETED(), VFP knows that the record is not deleted and can retrieve the record when you need it. Otherwise it has to read the record right away.

Christof
--
Christof
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform