90 lines
5.7 KiB
HTML
90 lines
5.7 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
|
<!DOCTYPE html
|
||
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html lang="en-us" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow" />
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<meta name="DC.Type" content="reference" />
|
||
|
|
<meta name="DC.Title" content="Specifying SEARCH consideration" />
|
||
|
|
<meta name="abstract" content="Certain applications dealing with hierarchical, recursive data, may have a requirement in how data is processed: by depth or by breadth." />
|
||
|
|
<meta name="description" content="Certain applications dealing with hierarchical, recursive data, may have a requirement in how data is processed: by depth or by breadth." />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzajqrecursive.htm" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="DC.Format" content="XHTML" />
|
||
|
|
<meta name="DC.Identifier" content="rzajqrctesearch" />
|
||
|
|
<meta name="DC.Language" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
|
<title>Specifying SEARCH consideration</title>
|
||
|
|
</head>
|
||
|
|
<body id="rzajqrctesearch"><a name="rzajqrctesearch"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Specifying SEARCH consideration</h1>
|
||
|
|
<div><p>Certain applications dealing with hierarchical, recursive data,
|
||
|
|
may have a requirement in how data is processed: by depth or by breadth.</p>
|
||
|
|
<div class="section"><p>Using a queuing (First In First Out) mechanism to keep track of
|
||
|
|
the recursive join key values implies the results are retrieved in breadth
|
||
|
|
first order. Breadth first means retrieving all the direct children of a
|
||
|
|
parent row before retrieving any of the grandchildren of that same row. This
|
||
|
|
is an implementation distinction, however, and not a guarantee. Applications
|
||
|
|
may want to guarantee how the data is retrieved. Some applications may want
|
||
|
|
to retrieve the hierarchical data in depth first order. Depth first means
|
||
|
|
that all the descendents of each immediate child row are retrieved before
|
||
|
|
the descendents of the next child are retrieved.</p>
|
||
|
|
<p>The SQL architecture
|
||
|
|
allows for the guaranteed specification of how the application retrieves the
|
||
|
|
resulting data by the use of the SEARCH DEPTH FIRST or BREADTH FIRST keyword.
|
||
|
|
When this option is specified along with naming the recursive join value,
|
||
|
|
identifying a set sequence column and providing the sequence column in an
|
||
|
|
outer ORDER BY clause, the results will be output in depth or breadth first
|
||
|
|
order. Note this is ultimately a relationship sort and not a value based sort.</p>
|
||
|
|
<p>Here
|
||
|
|
is the example above output in depth order.</p>
|
||
|
|
<pre><strong>WITH</strong> destinations (departure, arrival, connects, cost ) <strong>AS</strong>
|
||
|
|
(
|
||
|
|
<strong>SELECT</strong> f.departure, f.arrival, 0 , ticket
|
||
|
|
FROM flights f
|
||
|
|
WHERE f.departure='Chicago' <strong>OR</strong> f.departure='New York'
|
||
|
|
<strong>UNION ALL</strong>
|
||
|
|
<strong>SELECT</strong>
|
||
|
|
r.departure,b.arrival, r.connects+1 ,
|
||
|
|
r.cost+b.ticket
|
||
|
|
<strong>FROM</strong> destinations r, flights b
|
||
|
|
<strong>WHERE</strong> r.arrival=b.departure)
|
||
|
|
|
||
|
|
<strong>SEARCH DEPTH FIRST BY</strong> arrival <strong>SET</strong> depth_sequence
|
||
|
|
|
||
|
|
<strong>SELECT</strong> *
|
||
|
|
<strong>FROM</strong> destinations
|
||
|
|
<strong>ORDER BY</strong> depth_sequence</pre>
|
||
|
|
<p>If the ORDER BY clause is not specified in the main query,
|
||
|
|
the sequencing option is ignored. To facilitate the correct sort there is
|
||
|
|
additional information put on the queue entry during recursion. In the case
|
||
|
|
of BREADTH FIRST, it is the recursion level number and the immediate ancestor
|
||
|
|
join value, so sibling rows can be sorted together. A depth first search
|
||
|
|
is a little more data intensive. In the case of DEPTH FIRST, the query engine
|
||
|
|
needs to represent the entire ancestry of join values leading up to the current
|
||
|
|
row and puts that information in a queue entry. Also, because these sort values
|
||
|
|
are not coming from a external data source, the implementation for the sort
|
||
|
|
will always be a temporary sorted list (no indexes possible).</p>
|
||
|
|
<p>Do not
|
||
|
|
use the SEARCH option if you do not have a requirement that your data be materialized
|
||
|
|
in a depth or breadth first manner as there is additional CPU and memory overhead
|
||
|
|
to manage the sequencing information.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzajqrecursive.htm" title="Certain applications and data are recursive by nature. Examples of such applications are a bill-of-material, reservation, trip planner or networking planning system where data in one results row has a natural relationship (call it a parent, child relationship) with data in another row or rows. Although the kinds of recursion implemented in these systems can be performed by using SQL Stored Procedures and temporary results tables, the use of a recursive query to facilitate the access of this hierarchical data can lead to a more elegant and better performing application.">Recursive query optimization</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|