advanced.sgml
上传用户:blenddy
上传日期:2007-01-07
资源大小:6495k
文件大小:9k
源码类别:

数据库系统

开发平台:

Unix_Linux

  1. <Chapter Id="advanced">
  2. <Title>Advanced <ProductName>Postgres</ProductName> <Acronym>SQL</Acronym> Features</Title>
  3. <Para>
  4.      Having covered the basics  of  using  <ProductName>Postgres</ProductName>  <Acronym>SQL</Acronym>  to
  5.      access your data, we will now discuss those features of
  6.      <ProductName>Postgres</ProductName> that distinguish  it  from  conventional  data
  7.      managers.   These  features  include  inheritance, time
  8.      travel and non-atomic  data  values  (array-  and  
  9.      set-valued attributes).
  10.      Examples   in   this  section  can  also  be  found  in
  11.      <FileName>advance.sql</FileName> in the tutorial directory.
  12. (Refer to <XRef LinkEnd="QUERY"> for how to use it.)
  13. </Para>
  14. <Sect1>
  15. <Title>Inheritance</Title>
  16. <Para>
  17.      Let's create two classes. The capitals  class  contains
  18.      state  capitals  which  are also cities. Naturally, the
  19.      capitals class should inherit from cities.
  20.      
  21. <ProgramListing>
  22. CREATE TABLE cities (
  23.     name            text,
  24.     population      float,
  25.     altitude        int            -- (in ft)
  26. );
  27. CREATE TABLE capitals (
  28.     state           char2
  29. ) INHERITS (cities);
  30. </ProgramListing>
  31.      In this case, an  instance  of  capitals  <FirstTerm>inherits</FirstTerm>  all
  32.      attributes  (name,  population,  and altitude) from its
  33.      parent, cities.  The type  of  the  attribute  name  is
  34.      <Type>text</Type>,  a  native  <ProductName>Postgres</ProductName>  type  for variable length
  35.      ASCII strings.  The type of the attribute population is
  36.      <Type>float</Type>,  a  native <ProductName>Postgres</ProductName> type for double precision
  37.      floating point numbers.  State capitals have  an  extra
  38.      attribute, state, that shows their state.  In <ProductName>Postgres</ProductName>,
  39.      a  class  can inherit from zero or more other classes,
  40.      and a query can reference either  all  instances  of  a
  41.      class  or  all  instances  of  a  class plus all of its
  42.      descendants.
  43. <Note>
  44. <Para>
  45. The inheritance hierarchy is a  directed  acyclic graph.
  46. </Para>
  47. </Note>
  48. For example, the  following  query  finds
  49.      all  the cities that are situated at an attitude of 500ft or higher:
  50.      
  51. <ProgramListing>
  52. SELECT name, altitude
  53.     FROM cities
  54.     WHERE altitude &gt; 500;
  55. +----------+----------+
  56. |name      | altitude |
  57. +----------+----------+
  58. |Las Vegas | 2174     |
  59. +----------+----------+
  60. |Mariposa  | 1953     |
  61. +----------+----------+
  62. </ProgramListing>         
  63. </Para>
  64. <Para>
  65.      On the other hand, to find the  names  of  all  cities,
  66.      including  state capitals, that are located at an altitude 
  67.      over 500ft, the query is:
  68. <ProgramListing>
  69. SELECT c.name, c.altitude
  70.     FROM cities* c
  71.     WHERE c.altitude > 500;
  72. </ProgramListing>
  73.      which returns:
  74.      
  75. <ProgramListing>
  76. +----------+----------+
  77. |name      | altitude |
  78. +----------+----------+
  79. |Las Vegas | 2174     |
  80. +----------+----------+
  81. |Mariposa  | 1953     |
  82. +----------+----------+
  83. |Madison   | 845      |
  84. +----------+----------+
  85. </ProgramListing>
  86.      Here the <Quote>*</Quote> after cities indicates that the query should
  87.      be  run over cities and all classes below cities in the
  88.      inheritance hierarchy.  Many of the  commands  that  we
  89.      have  already discussed (<Command>select</Command>, <Command>update</Command> and <Command>delete</Command>)
  90.      support this <Quote>*</Quote> notation, as do others, like <Command>alter</Command>.
  91. </Para>
  92. </Sect1>
  93. <Sect1>
  94. <Title>Non-Atomic Values</Title>
  95. <Para>
  96.      One  of  the tenets of the relational model is that the
  97.      attributes of a relation are atomic.  <ProductName>Postgres</ProductName> does not
  98.      have  this  restriction; attributes can themselves contain 
  99.      sub-values that can be  accessed  from  the  query
  100.      language.   For example, you can create attributes that
  101.      are arrays of base types.
  102. </Para>
  103. <Sect2>
  104. <Title>Arrays</Title>
  105. <Para>
  106.      <ProductName>Postgres</ProductName> allows attributes of an instance to be defined
  107.      as  fixed-length  or  variable-length multi-dimensional
  108.      arrays. Arrays of any base type  or  user-defined  type
  109.      can  be created. To illustrate their use, we first create a 
  110.      class with arrays of base types.
  111.      
  112. <ProgramListing>
  113. CREATE TABLE SAL_EMP (
  114.     name            text,
  115.     pay_by_quarter  int4[],
  116.     schedule        text[][]
  117. );
  118. </ProgramListing>
  119. </Para>
  120. <Para>
  121.      The above query will create a class named SAL_EMP  with
  122.      a  <FirstTerm>text</FirstTerm>  string (name), a one-dimensional array of <FirstTerm>int4</FirstTerm>
  123.      (pay_by_quarter),  which  represents   the   employee's
  124.      salary by quarter and a two-dimensional array of <FirstTerm>text</FirstTerm>
  125.      (schedule),  which  represents  the  employee's  weekly
  126.      schedule.   Now  we  do  some  <FirstTerm>INSERTS</FirstTerm>s; note that when
  127.      appending to an array, we  enclose  the  values  within
  128.      braces  and  separate  them  by commas.  If you know <FirstTerm>C</FirstTerm>,
  129.      this is not unlike the syntax for  initializing  structures.
  130.      
  131. <ProgramListing>
  132. INSERT INTO SAL_EMP
  133.     VALUES ('Bill',
  134.     '{10000, 10000, 10000, 10000}',
  135.     '{{"meeting", "lunch"}, {}}');
  136. INSERT INTO SAL_EMP
  137.     VALUES ('Carol',
  138.     '{20000, 25000, 25000, 25000}',
  139.     '{{"talk", "consult"}, {"meeting"}}');
  140. </ProgramListing>
  141.      By  default,  <ProductName>Postgres</ProductName>  uses  the "one-based" numbering
  142.      convention for arrays -- that is, an array  of  n  elements starts with array[1] and ends with array[n].
  143.      Now,  we  can  run  some queries on SAL_EMP.  First, we
  144.      show how to access a single element of an  array  at  a
  145.      time.   This query retrieves the names of the employees
  146.      whose pay changed in the second quarter:
  147.      
  148. <ProgramListing>
  149. SELECT name
  150.     FROM SAL_EMP
  151.     WHERE SAL_EMP.pay_by_quarter[1] &lt;&gt;
  152.     SAL_EMP.pay_by_quarter[2];
  153. +------+
  154. |name  |
  155. +------+
  156. |Carol |
  157. +------+
  158. </ProgramListing>
  159. </Para>
  160. <Para>
  161.      This query retrieves  the  third  quarter  pay  of  all
  162.      employees:
  163.      
  164. <ProgramListing>
  165. SELECT SAL_EMP.pay_by_quarter[3] FROM SAL_EMP;
  166. +---------------+
  167. |pay_by_quarter |
  168. +---------------+
  169. |10000          |
  170. +---------------+
  171. |25000          |
  172. +---------------+
  173. </ProgramListing>
  174. </Para>
  175. <Para>
  176.      We  can  also  access  arbitrary slices of an array, or
  177.      subarrays.  This query  retrieves  the  first  item  on
  178.      Bill's schedule for the first two days of the week.
  179.      
  180. <ProgramListing>
  181. SELECT SAL_EMP.schedule[1:2][1:1]
  182.     FROM SAL_EMP
  183.     WHERE SAL_EMP.name = 'Bill';
  184. +-------------------+
  185. |schedule           |
  186. +-------------------+
  187. |{{"meeting"},{""}} |
  188. +-------------------+
  189. </ProgramListing>
  190. </Para>
  191. </sect2>
  192. </Sect1>
  193. <Sect1>
  194. <Title>Time Travel</Title>
  195. <Para>
  196. As of <ProductName>Postgres</ProductName> v6.2, <Emphasis>time travel is no longer supported</Emphasis>. There are
  197. several reasons for this: performance impact, storage size, and a pg_time file which grows
  198. toward infinite size in a short period of time.
  199. </Para>
  200. <Para>
  201. New features such as triggers allow one to mimic the behavior of time travel when desired, without
  202. incurring the overhead when it is not needed (for most users, this is most of the time).
  203. See examples in the <FileName>contrib</FileName> directory for more information.
  204. </Para>
  205. <Note>
  206. <Title>Time travel is deprecated</Title>
  207. <Para>
  208. The remaining text in this section is retained only until it can be rewritten in the context
  209. of new techniques to accomplish the same purpose. Volunteers? - thomas 1998-01-12
  210. </Para>
  211. </Note>
  212. <Para>
  213.      <ProductName>Postgres</ProductName> supports the notion of time travel.  This feature 
  214.      allows a user  to  run  historical  queries.   For
  215.      example,  to  find  the  current population of Mariposa
  216.      city, one would query:
  217.      
  218. <ProgramListing>
  219. SELECT * FROM cities WHERE name = 'Mariposa';
  220. +---------+------------+----------+
  221. |name     | population | altitude |
  222. +---------+------------+----------+
  223. |Mariposa | 1320       | 1953     |
  224. +---------+------------+----------+
  225. </ProgramListing>
  226.      <ProductName>Postgres</ProductName> will automatically find the version  of  Mariposa's 
  227.      record valid at the current time.
  228.      One can also give a time range.  For example to see the
  229.      past and present populations  of  Mariposa,  one  would
  230.      query:
  231.      
  232. <ProgramListing>
  233. SELECT name, population
  234.     FROM cities['epoch', 'now']
  235.     WHERE name = 'Mariposa';
  236. </ProgramListing>
  237.      where  "epoch"  indicates  the  beginning of the system
  238.      clock.
  239. <Note>
  240. <Para>
  241. On UNIX systems, this is always  midnight,  January  1, 1970 GMT.
  242. </Para>
  243. </Note>
  244. </Para>
  245. <Para>
  246.      If  you  have  executed all of the examples so
  247.      far, then the above query returns:
  248.      
  249. <ProgramListing>
  250. +---------+------------+
  251. |name     | population |
  252. +---------+------------+
  253. |Mariposa | 1200       |
  254. +---------+------------+
  255. |Mariposa | 1320       |
  256. +---------+------------+
  257. </ProgramListing>
  258. </Para>
  259. <Para>
  260.      The default beginning of a time range is  the  earliest
  261.      time representable by the system and the default end is
  262.      the current time; thus, the above  time  range  can  be
  263.      abbreviated as ``[,].''
  264. </Para>
  265. </sect1>
  266. <Sect1>
  267. <Title>More Advanced Features</Title>
  268. <Para>
  269. <ProductName>Postgres</ProductName> has many features not touched upon in this
  270. tutorial introduction, which has been oriented toward newer users of <Acronym>SQL</Acronym>.
  271. These are discussed in more detail in both the User's and Programmer's Guides.
  272. </Para>
  273. </sect1>
  274. </Chapter>