I would say that you should learn a bit about relational databases
before you start working with them ;-)
All unique fields (or combinations of fields that -combined- are unique)
can serve as a primary key.
In relational databases we call them 'candidate key'.
if you have more than one candidate key in a table, there's nothing
wrong. You just simply choose.
Best choices are:
- select the set of the least amount of columns. (preferably only one)
- if you still have more than one candidate key, choose a column with an
integer (as integers are looked up the fastest, and you want your
indexes to be fast)
- if you still have more than one candidate key, pick one
That one you define as your primary key. By defenition a primary key is
unique. But not all unique fields are primary key.
The primary index is the index that should be chosen most, because it is
your fastest or best index. From my experience it is always the index of
your primary key, since the reasons for selecting the primary index are
normally about speed.
How you can create your indexes best, and how many you create and how
you create them are beyond the scope of this mail. I suggest you read
the documentation about the indexes.
Also get a book about basics of relational databases, it is really
useful! Also getting yourself informed about normalisation (usually up
to the 3rd form suffices) can help you on your way.
- Michiel
orange_crush_068@hotmail.com wrote:
>What are the major differences between Unique, primary index & just
>plain index?
>
>When creating tables I nominate one of these, but not sure what the
>difference is?
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 8: explain analyze is your friend
>
>
>
>
>
