Tore,
Thanks very much for taking the time to respond! I'm not insulted by
"basic". Some things I knew, but my questions were basic.
> 1: There is no difference: KEY is a synonym for INDEX.
So these two statements are equivalent:
KEY [index_name] (index_col_name,...)
INDEX [index_name] (index_col_name,...)
I suspected this.
> 2: In a syntax description, the use of [square] brackets means that the
part
in brackets is optional. Whether you include it or not doesn't change the
semantics.
So you're saying that you can write "UNIQUE" or "UNIQUE INDEX" and it means
the same thing? I know that parameters in brackets are optional, but usually
the use of an option changes the meaning of the statement. In this case it
doesn't--okay.
> 3: I don't know why Dreamweaver adds the KEY PRIMARY_KEY definition.
Me, either. I won't worry about it.
> 4: The name of an index does not determine whether it gets used or not.
So if I have a primary index on CustID, it will be used if I reference
"CustID" rather than PRIMARY? Why does the index have a name if it's never
used? Are there situations where you should use the index name rather than
the name of the column that is indexed?
> 5: <snip> The FORIGN KEY statement is there to implement referential
integrity
in the database through declarative rules. Of course, you can be sloppy and
just
not declare the relationships, just construct your queries as if the data is
OK... But I won't recommend it.
I checked the manual and only InnoDB tables support these rules. I've been
using MyISAM. Do you think I should change to InnoDB?
> <snip> I have been unable to verify whether the CHECK constraint is
actually
implemented with any table types or in any versions of MySQL.
I rechecked the manual (now that I can read it more easily). This is only
available on InnoDB tables on MySQL 3.23.44 or later (like the FOREIGN KEY
and REFERENCES syntax).
Thanks again for your help.
- Sheryl

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.