Log Message:
-----------
Improve phrasing (no offence to Andreas intended - his English is still 
waaaaaaayyyyy better than my German :-) )

Modified Files:
--------------
    pgadmin3/docs/en_US/hints:
        pk.html (r1.2 -> r1.3)

Index: pk.html
===================================================================
RCS file: /projects/pgadmin3/docs/en_US/hints/pk.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -Ldocs/en_US/hints/pk.html -Ldocs/en_US/hints/pk.html -u -w -r1.2 -r1.3
--- docs/en_US/hints/pk.html
+++ docs/en_US/hints/pk.html
@@ -10,10 +10,10 @@
 
 <h3>Primary keys</h3>
 <p>
-When designing a table, you should always keep in mind how the table will be 
adressed 
+When designing a table, you should always keep in mind how the table will be 
addressed 
 later. In most cases, you will need an identifier in order to uniquely address 
a specific 
-row; this identifier should be created as your primary key. A primary key 
isn't 
-necessarily consisting of a single column; it may contain as many rows as 
necessary 
+row; this identifier should be created as your primary key. A primary key 
needn't 
+necessarily consist of a single column; it may contain as many columns as 
necessary 
 to uniquely identify a row. If you need many columns (rule of thumb: more than 
3), it might be a good
 idea to invent an additional column with a convenient data type, e.g. serial 
or bigserial, which holds the primary key.
 </p>
@@ -24,7 +24,7 @@
 </p>
 <p>
 If you look at PostgreSQL's system tables, you will find that none of them has 
a primary key, so what's this about?
-Actually, All of these tables have one or two columns (usually OID only) which 
uniquely identifies the row, obeying the
+Actually, All of these tables have one or two columns (usually OID only) which 
uniquely identifies each row, obeying the
 second rule for a primary key, not allowing zero, and being covered by an 
index for faster access. Usage of OIDs has 
 historic reasons, and isn't really first choice for designing user tables. 
PostgreSQL still uses this for backwards compatibility, 
 and while a newer approach would probably use explicit primary keys it won't 
be changed now any more.
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq

Reply via email to