Proper Indexing of Table Fields

  • Thread starter Thread starter QB
  • Start date Start date
Q

QB

Correct me if I misunderstood, but I read that one should index fields that
are used as criteria in queries.

With this in mind, when one does a caculated field in a query using multiple
table fields, this means I should index each of these as well?

Ie:
(oldValue - newValue)/oldValue As PercentDiff

I should index oldValue and newValue?

Thank you,

QB
 
.... it depends ... <G>

If your table has a few thousand rows, if your database isn't split, if you
only have one user at a time, ...
you might not need indexing.

If you have 100's of thousands of rows, if the back-end/data is on a slow
LAN, in a db server, if ...
you might need indexing.

What performance differences have you seen when you tried it?

Regards

Jeff Boyce
Microsoft Access MVP

--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.
 
So based on your post, it is a trial and error thing?!

Here is the scenario:
Access 2003
Split Db
No server, simply shared off of a NAS Drive -- Each user has the FE
10 or less users
biggest table currently hold 130K records but the db is growing steadily
(currently BE at 54MB) probably 75K-100K records a year to the biggest table.

I haven't had the chance to do testing on indexing, that is why I wanted to
get some advice on the matter before I try and delve into it. I don't want
to make useless mistake and am more than willing to learn form people such as
yourself (people with far more knowledge and experience on the matter).

Is there a drawback to indexing fields? What about indexing fields that
aren't used in queries as criteria (over-indexing)? Does indexing add load
to database processing (I'm assuming so or else you would have told me to
index to my heart's content :-) )?

Thank you,

QB
 
Correct me if I misunderstood, but I read that one should index fields that
are used as criteria in queries.

With this in mind, when one does a caculated field in a query using multiple
table fields, this means I should index each of these as well?

Ie:
(oldValue - newValue)/oldValue As PercentDiff

I should index oldValue and newValue?

Thank you,

QB
Click to expand...

Indexing the underlying fields in a calculated expression will not help, if
you're applying criteria to PercentDiff: it will still have to retrieve all
the rows, do the calculation on all of them, and only then apply the
criterion.

If you find performance is unacceptable (try it first, you might be pleasantly
surprised), post back with the actual criterion you're using; it may be that
some alternative way of framing the question will allow you to search for all
NewValues based on some expression on OldValue. Failing that, this might be
one of the rare instances where it's appropriate to store a derived value.
 
Is there a drawback to indexing fields? What about indexing fields that
aren't used in queries as criteria (over-indexing)? Does indexing add load
to database processing (I'm assuming so or else you would have told me to
index to my heart's content :-) )?
Click to expand...

Indexes speed data retrieval but they *slow* data insertion or updating (the
program must update not only the table but all the indexes that are touched by
a change of the data); there is also a limit of 32 indexes on any one table.
In addition indexes do take up room in the database, counting toward the
2GByte limit on the size of the database.
 
As John points out, each situation is different.

If I were faced with deciding which fields to index, yes, I'd probably "try"
some different approaches to see which worked best.

But "trial and error" implies not using any intelligence...

If you have a field that has only 2 or 3 different values across 100,000
records, indexing is not going to help much!

If you have only 1,000 records, indexing might help, but most humans would
never be able to tell the difference!

If you are selecting on it, sorting by it, or joining on it, it's a
potential index.

Good luck!

Regards

Jeff Boyce
Microsoft Access MVP

--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.
 
No server, simply shared off of a NAS Drive -- Each user has the FE
Click to expand...

On a side note, I'm concerned about the BE on a NAS. Be aware that if
the back-end is on an OS without the right file locking mechanisms,
very bad corruption can result when multiple users make changes.

Look at the BE folder. If the LDB locking file disappears when
subsequent users start using the database, that's one sign that you're
headed for trouble. Move the BE to a Windows machine.

Armen Stein
Microsoft Access MVP
www.JStreetTech.com
 
The WD NAS is running NTFS, so from what I know this should be fine (unless
you tell me otherwise) and the ldb remains intact with multiple user
connection.

QB
 
Back
Top