mirror of
https://github.com/postgres/postgres.git
synced 2025-05-01 01:04:50 +03:00
Remove unused file (the information is already contained elsewhere).
This commit is contained in:
Peter Eisentraut
parent
a412749812
commit
de3379503a
@ -1,186 +0,0 @@
|
|||||||
<!--
|
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/keys.sgml,v 1.7 2000/12/22 21:51:58 petere Exp $
|
|
||||||
Indices and Keys
|
|
||||||
-->
|
|
||||||
|
|
||||||
<chapter id="keys">
|
|
||||||
<docinfo>
|
|
||||||
<authorgroup>
|
|
||||||
<author>
|
|
||||||
<firstname>Herouth</firstname>
|
|
||||||
<surname>Maoz</surname>
|
|
||||||
</author>
|
|
||||||
</authorgroup>
|
|
||||||
<date>1998-03-02</date>
|
|
||||||
</docinfo>
|
|
||||||
|
|
||||||
<title>Indices and Keys</title>
|
|
||||||
|
|
||||||
<note>
|
|
||||||
<title>Author</title>
|
|
||||||
<para>
|
|
||||||
Written by Herouth Maoz
|
|
||||||
(<email>herouth@oumail.openu.ac.il</email>)
|
|
||||||
</para>
|
|
||||||
</note>
|
|
||||||
|
|
||||||
<note>
|
|
||||||
<title>Editor's Note</title>
|
|
||||||
<para>
|
|
||||||
This originally appeared on the mailing list
|
|
||||||
in response to the question:
|
|
||||||
"What is the difference between PRIMARY KEY and UNIQUE constraints?".
|
|
||||||
</para>
|
|
||||||
</note>
|
|
||||||
|
|
||||||
<programlisting>
|
|
||||||
Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE
|
|
||||||
|
|
||||||
What's the difference between:
|
|
||||||
|
|
||||||
PRIMARY KEY(fields,...) and
|
|
||||||
UNIQUE (fields,...)
|
|
||||||
|
|
||||||
- Is this an alias?
|
|
||||||
- If PRIMARY KEY is already unique, then why
|
|
||||||
is there another kind of key named UNIQUE?
|
|
||||||
</programlisting>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
A primary key is the field(s) used to identify a specific row. For example,
|
|
||||||
Social Security numbers identifying a person.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
A simply UNIQUE combination of fields has nothing to do with identifying
|
|
||||||
the row. It's simply an integrity constraint. For example, I have
|
|
||||||
collections of links. Each collection is identified by a unique number,
|
|
||||||
which is the primary key. This key is used in relations.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
However, my application requires that each collection will also have a
|
|
||||||
unique name. Why? So that a human being who wants to modify a collection
|
|
||||||
will be able to identify it. It's much harder to know, if you have two
|
|
||||||
collections named "Life Science", the the one tagged 24433 is the one you
|
|
||||||
need, and the one tagged 29882 is not.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
So, the user selects the collection by its name. We therefore make sure,
|
|
||||||
withing the database, that names are unique. However, no other table in the
|
|
||||||
database relates to the collections table by the collection Name. That
|
|
||||||
would be very inefficient.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
Moreover, despite being unique, the collection name does not actually
|
|
||||||
define the collection! For example, if somebody decided to change the name
|
|
||||||
of the collection from "Life Science" to "Biology", it will still be the
|
|
||||||
same collection, only with a different name. As long as the name is unique,
|
|
||||||
that's OK.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
So:
|
|
||||||
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Primary key:
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Is used for identifying the row and relating to it.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Is impossible (or hard) to update.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Should not allow NULLs.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Unique field(s):
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Are used as an alternative access to the row.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Are updateable, so long as they are kept unique.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
NULLs are acceptable.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
As for why no non-unique keys are defined explicitly in standard
|
|
||||||
<acronym>SQL</acronym> syntax?
|
|
||||||
Well, you
|
|
||||||
must understand that indices are implementation-dependent. <acronym>SQL</acronym> does not
|
|
||||||
define the implementation, merely the relations between data in the
|
|
||||||
database. <productname>Postgres</productname> does allow non-unique indices, but indices
|
|
||||||
used to enforce <acronym>SQL</acronym> keys are always unique.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
Thus, you may query a table by any combination of its columns, despite the
|
|
||||||
fact that you don't have an index on these columns. The indexes are merely
|
|
||||||
an implementational aid that each <acronym>RDBMS</acronym> offers you, in order to cause
|
|
||||||
commonly used queries to be done more efficiently. Some <acronym>RDBMS</acronym> may give you
|
|
||||||
additional measures, such as keeping a key stored in main memory. They will
|
|
||||||
have a special command, for example
|
|
||||||
<programlisting>
|
|
||||||
CREATE MEMSTORE ON <table> COLUMNS <cols>
|
|
||||||
</programlisting>
|
|
||||||
(this is not an existing command, just an example).
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
In fact, when you create a primary key or a unique combination of fields,
|
|
||||||
nowhere in the <acronym>SQL</acronym> specification does it say that an index is created, nor that
|
|
||||||
the retrieval of data by the key is going to be more efficient than a
|
|
||||||
sequential scan!
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
So, if you want to use a combination of fields that is not unique as a
|
|
||||||
secondary key, you really don't have to specify anything - just start
|
|
||||||
retrieving by that combination! However, if you want to make the retrieval
|
|
||||||
efficient, you'll have to resort to the means your <acronym>RDBMS</acronym> provider gives you
|
|
||||||
- be it an index, my imaginary MEMSTORE command, or an intelligent
|
|
||||||
<acronym>RDBMS</acronym>
|
|
||||||
that creates indices without your knowledge based on the fact that you have
|
|
||||||
sent it many queries based on a specific combination of keys... (It learns
|
|
||||||
from experience).
|
|
||||||
</para>
|
|
||||||
</chapter>
|
|
||||||
|
|
||||||
<!-- Keep this comment at the end of the file
|
|
||||||
Local variables:
|
|
||||||
mode:sgml
|
|
||||||
sgml-omittag:nil
|
|
||||||
sgml-shorttag:t
|
|
||||||
sgml-minimize-attributes:nil
|
|
||||||
sgml-always-quote-attributes:t
|
|
||||||
sgml-indent-step:1
|
|
||||||
sgml-indent-data:t
|
|
||||||
sgml-parent-document:nil
|
|
||||||
sgml-default-dtd-file:"./reference.ced"
|
|
||||||
sgml-exposed-tags:nil
|
|
||||||
sgml-local-catalogs:("/usr/lib/sgml/catalog")
|
|
||||||
sgml-local-ecat-files:nil
|
|
||||||
End:
|
|
||||||
--></book>
|
|
||||||
Loading…
x
Reference in New Issue
Block a user