On Monday, March 18, 2002, at 03:40 PM, Jennifer Downey wrote:
> Just wondering, does a table have to have an index? If so what should I
> consider when making a colum an index?
You're not required to have an index, as far as I know. It's just that
an index is a way of optimizing retrievals to and from the table. Think
of an index as a mini-table or meta-table that keeps track of a specific
column in your actual table -- the RDBMS prefers to store all of the
data in its own order, but the index stores a map of one of those
columns according to a more search-friendly order.
The rule of thumb with indexes is to use indexes on columns that you
search frequently. So, if you rarely do any searches based on
pet_hunger, then don't index that. But you might often do lookups for
pet_name, so that would be a good one to index.
Although you have a petid column, it's VARCHAR and thus I have a feeling
it's not a "traditional" ID column. By that I mean it's not a column
with a unique value for each row in the table. If you really want to
take advantage of the true power of a RDBMS, you should create a
"traditional" ID column like the following:
pet_uniq_id PRIMARY KEY AUTO_INCREMENT NOT NULL
which will automatically generate a new unique value each time you add a
record. This will help you immeasurably if you ever decide to normalize
this table. From what I can tell, your table as is does not appear to
be normalized, which means that while it may be functional, you're not
making the most of what your RDBMS gives you to work with.
Strongly recommended book: "MySQL" by Paul DuBois (New Riders).
Web Developer Temp
Media Lab, H.H. Brown
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php