Remove unused file (the information is already contained elsewhere).

doc/src/sgml/keys.sgml

-<!--
-$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 &lt;table&gt; COLUMNS &lt;cols&gt;
-   </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>