Nester inner joins

SELECT order_head.ID col
FROM
order order_head
INNER JOIN customer customer_2 ON order_head.customerID = customer_2.ID
WHERE
order_head.orderDate BETWEEN '12/12/2001'
AND '12/12/2009'
AND order_head.ID <> 0
AND customer_2.LastName = 'smith'
AND order_head.status = 1
INNER JOIN (customer_2 INNER JOIN order_head ON customer_2.ID = order_head.customerID) ON cust_address.ID = customer_2.AddressID )
WHERE cust_address.postcode = 'NW1 9PQ'
Error : Incorrect syntax near the keyword 'INNER'.
The last bit in bold does not work the other stuff works correctly, what I am trying to do that does not work is find orders from customers with last name of smith and post code of 'NW1 9PQ', it is unfortunate that the tables are from a third party and cannot be changed and so I am stuck with the table structure. I am also trying to stick with joins.
I have tested this inner join in isolation and appears to work fine !!!!
Any suggestions or pointers will be most appriciated, thanks in advance....
BM

[email protected] wrote:
Error : Incorrect syntax near the keyword 'INNER'.
The last bit in bold does not work the other stuff works correctly, what I am trying to do that does not work is find orders from customers with last name of smith and post code of 'NW1 9PQ', it is unfortunate that the tables are from a third party and cannot be changed and so I am stuck with the table structure. I am also trying to stick with joins.
I have tested this inner join in isolation and appears to work fine !!!!
Any suggestions or pointers will be most appriciated, thanks in advance....BM,
probably you just need follow the correct syntax described in the previous post and put first the join operators. If you really think you have the need to use nested query, you could use an approach like that:
SELECT order_head.ID col
FROM order order_head
INNER JOIN customer customer_2 ON order_head.customerID = customer_2.ID
INNER JOIN (
select c2.* from customer c2 INNER JOIN order o2 ON c2.ID = o2.customerID
) cust_address ON cust_address.ID = customer_2.AddressID
WHERE order_head.orderDate BETWEEN '12/12/2001'
AND '12/12/2009'
AND order_head.ID <> 0
AND customer_2.LastName = 'smith'
AND order_head.status = 1
AND cust_address.postcode = 'NW1 9PQ'Probably above statement doesn't make sense content-wise but I just wanted to use it for illustrative purposes that you can use nested subqueries like that.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

Similar Messages

  • Help:Nested Inner Join

    Hello Folks,
    I have a query which has a nested Inner Join as follows
    INNER JOIN(Client
    INNER JOIN CUBS SNAPSHOT ON Client . Client = CUBS SNAPSHOT . CLIENT) ON CancelDesc . CancelReason = CUBS SNAPSHOT . CANCELREASONcouldnt figure out wat is the quivalent of this nested inner join in Oracle Server. I am trying to create a report based on this inner join of a query. Can anyone throw some light on this.
    Thanks

    Hi,
    Inner joins don't need to be nested. The results will be the same, no matter in what order the tables are joined.
    In Oracle, don't use table names with spaces in them, and don't put spaces before or after the dots that separate table name qualifiers from column names.
    I think this is what you want:
    INNER JOIN     cubs_snapshot  ON     CancelDesc.CancelReason = cubs_snapshot.cancelreason
    INNER JOIN     Client            ON     Client.Client           = cubs_snapshot.clientWhenever you have a question, post a little sample data (CREATE TABLE and INSERT statememts) for all tables invlovled, and the results you want from that data.
    If you really did need to nest joins, you could join some tables in a sub-query, then use the result set of that sub-query as if it were a table.
    For example:
    WITH  cubs_and_client            AS
         SELECT     CancelReason
         ,     ...     -- Whatever other columns are needed in superior query or queries
         FROM          client
         INNER JOIN     cubs_snapshot     ON     Client.Client           = cubs_snapshot.client
    SELECT     
    INNER JOIN     cubs_and_client     ON     CancelDesc.CancelReason = cubs_and_client.CancelReason
    ...In this example, the two tables cubs_snapshot and client are joined in a sub-query. The results of that sub-query can be referenced later in the query as if it were a table called cubs_and_client, very much like a view.

  • Avoiding inner joins????

    Hi all,
    I was just thinking of ways to improve the perfomance of my report. Its fetching data in to two different tables using two innerjoins and these two internal tables are again looped for some other manipulation. Can anyone tell me the ways i can avoid innerjoin or is there other ways to improve psrfomance by avoiding innejoins in general?
    Rakesh

    hi sir i was able to find out that
    Using several nested INNER JOIN statements can be inefficient and cause time out if the tables become too big in the future."
    Joins here (in ABAP) are not those Native SQL Joins.  If you are talking about the Core RDBMS, which mean Oracle or SQL Server, then Undoubtedly Joins are the best.
    In ABAP, these joins are first split by the ABAP processor and then sent to the database, with the increase in DATA in production system, these joins tend to give way if your database keeps growing larger and larger.
    You should rather used "FOR ALL ENTRIES IN" (Tabular conditions), which is a much effecient way as far as performance is concerned.
    For example :
    DATA: BEGIN OF LINE,
            CARRID   TYPE SPFLI-CARRID,
            CONNID   TYPE SPFLI-CONNID,
            CITYFROM TYPE SPFLI-CITYFROM,
            CITYTO   TYPE SPFLI-CITYTO,
          END OF LINE,
          ITAB LIKE TABLE OF LINE.
    LINE-CITYFROM = 'FRANKFURT'.
    LINE-CITYTO   = 'BERLIN'.
    APPEND LINE TO ITAB.
    LINE-CITYFROM = 'NEW YORK'.
    LINE-CITYTO   = 'SAN FRANCISCO'.
    APPEND LINE TO ITAB.
    SELECT CARRID CONNID CITYFROM CITYTO
    INTO   CORRESPONDING FIELDS OF LINE
    FROM   SPFLI
    FOR ALL ENTRIES IN ITAB
    WHERE  CITYFROM = ITAB-CITYFROM AND CITYTO = ITAB-CITYTO.
      WRITE: / LINE-CARRID, LINE-CONNID, LINE-CITYFROM, LINE-CITYTO.
    ENDSELECT.
    Do you have a ABAP Question?
    Best regards,
    SAP Basis, ABAP Programming and Other IMG Stuff

  • Inner joins  Vs  for all entries

    Hi All,
    Pls let me know
    the differences b/w innerjoins and for all entries,,,,which is the best option and  Y??
    Thanks in Advance,
    Bye

    Hi!
    INNER JOIN is used if we want to retrieve some data from more than one table.
    FOR ALL ENTRIES is used if we want some data from a table based on some conditions of some other table.
    Using several nested INNER JOIN statements can be inefficient and cause time out if the tables become too big in the future."
    In ABAP, these joins are first split by the ABAP processor and then sent to the database, with the increase in DATA in production system, these joins tend to give way if your database keeps growing larger and larger.
    You should rather use "FOR ALL ENTRIES IN" (Tabular conditions), which is a much efficient way as far as performance is concerned.
    Check these links:
    inner joins and for all entries
    inner join and for all entries
    Reward points if it helps.
    Regards
    Sudheer

  • Inner / outer table in nested loops join

    I can't understand what 'inner' / 'outer'
    table means in nested loops join operation.
    please explain the exact meaning.
    maybe i do not understand the nested loops
    join itself. I tried to find the meanings
    in Oracle manual, but I couldn't.

    If I understand correctly your question. An outer table loop is where you have a table with a primary key (master table) and you want to iterate into that table which have details forign key (inner loop table) for example you have customers table each have many invoices.
    hope that ansowers your query.
    <BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by 4baf:
    I can't understand what 'inner' / 'outer'
    table means in nested loops join operation.
    please explain the exact meaning.
    maybe i do not understand the nested loops
    join itself. I tried to find the meanings
    in Oracle manual, but I couldn't.<HR></BLOCKQUOTE>
    null

  • For All Entries is NOT better than INNER JOIN in most cases

    I quote from Siegfried Boes' excellent post here: Will writing an inner join be better or creating a view?
    For all the FOR ALL ENTRIES lovers ... there is no proof for these reappearing recommendation.
    There is nearly nobody who receives forum points, who recommends FOR ALL ENTRIES instead of Joins. What is the reason ???
    It is easier to prove the opposite. A Join is a nested loop inside the database, a FOR ALL ENTRIES is partly outside of the database. FOR ALL ENTRIES works in blocks, joins on totals.
    FOR ALL ENTRIES are not recommded on really large tables, because the chances are too high that
    too many records are transferred.
    People prefer FOR ALL ENTRIES, because JOINs are not so easy to understand. Joins can go wrong, but with a bit of understanding they can be fixed.
    Some Joins are slow and can not be fixed, but then the FOR ALL ENTRIES would be extremely slow.
    There are several kinds of views:
    - projection views, i.e. only one table involved just fields reduced
    - join views, several tables, joins conditions stored in dictionary
    - materialized views, here the joined data are actually stored in the database. Storing and synchronisation has to be done manually.
    Only the last one creates real overhead. It should be the exception.
    Join Views and Joins are nearly identical. The view is better for reuse. The join is better in complicated, becuase if the access goes wrong, it can often be fixed by adding a hint. Hints can not be added to views.
    Abraham Bukit  points out:
    If it is cluster table, (you can't use join). If it is buffered table, I would also say avoid join.
    If they all are transaction table which are not buffered and are not cluster tables.  
    He further supports Siegfried's statement that FAE is easier to undestand than INNER JOINs.
    Thomas Zloch says, regarding buffered tables:
    At least think twice, maybe compare runtimes if in doubt. 
    So, unless someone has some EVIDENCE that FOR ALL ENTRIES is better, I don't think we want to see this discussed further.
    Kind regards
    Matt

    To give food for thought here's an example I  gave in a thread:
    If you have a statement like
    SELECT ... FOR ALL ENTRIES IN FAE_itab WHERE f = FAE_itab-f.
    SAP sends it to the database depending how the parameter rsdb/prefer_union_all is set:
    rsdb/prefer_union_all = 0 =>
    SELECT ... WHERE f = FAE_itab[1]-f
              OR    f = FAE_itab[2]-f
              OR    f = FAE_itab[N]-f
    You have some influence  of the generated statement type: Instead of OR'ed fields an IN list can be used
    if you have only a single coulmn N to compare:
    rsdb/prefer_in_itab_opt parameter:
    SELECT ... WHERE f IN (itab[1]-f, itab[2]-f, ..., itab[N]-f)
    rsdb/prefer_union_all = 1 =>
    SELECT ... WHERE f = FAE_itab[1]-f
    UNION ALL SELECT ... WHERE f = FAE_itab[2]-f
    UNION ALL SELECT ... WHERE f = FAE_itab[N]-f
    see: Note 48230 - Parameters for the SELECT ... FOR ALL ENTRIES statement
    As you can see for the 2nd parameter several statements are generated and combined with a UNION ALL,
    the first setting generates statements with OR's (or uses IN  if possible) for the entries in FAE_itab.
    I give you a little example here (my parameters are set in a way that the OR's are translated to IN lists; i traced the execution in ST05)
    Select myid into table t_tabcount from mydbtable
      for all entries in t_table    " 484 entries
        where myid = t_table-myid .
    ST05 trace:
    |Transaction SEU_INT|Work process no 0|Proc.type  DIA|Client  200|User |
    |Duration |Obj. name |Op.    |Recs.|RC    |Statement|
    | 640|mydbtable |PREPARE|   |  0|SELECT WHERE "myid" IN ( :A0 , :A1 , :A2 , :A3 , :A4 ) AND "myid" = :A5|
    | 2|mydbtable |OPEN   |   |  0|SELECT WHERE "myid" IN ( 1 , 2 , 3 , 4 , 5 ) AND "myid" = 72 |
    | 2.536|mydbtable |FETCH  |    0|  1403|   |
    | 3|mydbtable |REOPEN |   |  0|SELECT WHERE "myid" IN ( 6 , 7 , 8 , 9 , 10 ) AND "myid" = 72 |
    | 118|mydbtable |FETCH  |  0|  |
    | 2|mydbtable |REOPEN |  |  0|SELECT WHERE "myid" IN ( 11 , 12 , 13 , 14 , 15 ) AND "myid" = 72     |
    | 3|mydbtable |REOPEN |  |  0|SELECT WHERE "myid" IN ( 475 , 476 , 477 , 478 , 479 ) AND "myid" = 72  |
    | 94|mydbtable |FETCH  | 0| 1403|   |
    | 2|mydbtable |REOPEN |   |  0|SELECT WHERE "myid" IN ( 480 , 481 , 482 , 483 , 484 ) AND "myid" = 72 |
    You see the IN list contained 5 entries each , wich made up about 97 statements for all 484 entries.
    For every statment you have a single fetch operation wich means a separate access to the database.
    If you would replace the FAE with a join you would only have one fetch to the database.
    With the example above we can derive these observations:
    1. From database point of view these settings kill performance when you access a big table and/or have a lot of entries or columns in your FAE_itab. Furthermore, you hide information what data you will access
    at all and thus you block the database from creating a more efficient execution plan because it DOESN'T KNOW wich data you will select in the next step. I.e. it may be more efficient to scan the table in one shot instead of having many index accesses - but the database can make this decision only if it can examine ONE statement that has ALL the information of what data to retrieve.
    2. A second impact is that with every statement execution you trigger the allocation of database resources
    wich will contribute to the overhead described above.
    Said that, FAE  can never be a replacement for joining big tables (think of having a table with thousands of records in a FAE table )
    Edited by: kishan P on Nov 2, 2010 2:16 PM - Format Fixed

  • Query related to inner join V/S all entries........

    Hi all,
    I have a dought ...related to join and all entries
    Which one will be the better as per performance prospective :
    1>For all entries
    or
    2> using inner join condition
    i am combining 2 tables ...
    but in my where clause is having 6-7 condition if i used inner join concept...
    Please let me know thanks for the help...in advance
    regards
    Amit

    Check Re: Multiple Table Join instead of Nested Selects? I wrote a program that compares the performance of a join against for all entries. The join won. But the best thing to do is for you test and compare both methods for your particular situation.
    In a select, the most important factor is the use of an index.
    Rob

  • Very Slow Query with CTE inner join

    I have 2 tables (heavily simplified here to show relevant columns):
    CREATE TABLE tblCharge
    (ChargeID int NOT NULL,
    ParentChargeID int NULL,
    ChargeName varchar(200) NULL)
    CREATE TABLE tblChargeShare
    (ChargeShareID int NOT NULL,
    ChargeID int NOT NULL,
    TotalAmount money NOT NULL,
    TaxAmount money NULL,
    DiscountAmount money NULL,
    CustomerID int NOT NULL,
    ChargeShareStatusID int NOT NULL)
    I have a very basic View to Join them:
    CREATE VIEW vwBASEChargeShareRelation as
    Select c.ChargeID, ParentChargeID, s.CustomerID, s.TotalAmount, isnull(s.TaxAmount, 0) as TaxAmount, isnull(s.DiscountAmount, 0) as DiscountAmount
    from tblCharge c inner join tblChargeShare s
    on c.ChargeID = s.ChargeID Where s.ChargeShareStatusID < 3
    GO
    I then have a view containing a CTE to get the children of the Parent Charge:
    ALTER VIEW [vwChargeShareSubCharges] AS
    WITH RCTE AS
    SELECT ParentChargeId, ChargeID, 1 AS Lvl, ISNULL(TotalAmount, 0) as TotalAmount, ISNULL(TaxAmount, 0) as TaxAmount,
    ISNULL(DiscountAmount, 0) as DiscountAmount, CustomerID, ChargeID as MasterChargeID
    FROM vwBASEChargeShareRelation Where ParentChargeID is NULL
    UNION ALL
    SELECT rh.ParentChargeID, rh.ChargeID, Lvl+1 AS Lvl, ISNULL(rh.TotalAmount, 0), ISNULL(rh.TaxAmount, 0), ISNULL(rh.DiscountAmount, 0) , rh.CustomerID
    , rc.MasterChargeID
    FROM vwBASEChargeShareRelation rh
    INNER JOIN RCTE rc ON rh.PArentChargeID = rc.ChargeID and rh.CustomerID = rc.CustomerID
    Select MasterChargeID as ChargeID, CustomerID, Sum(TotalAmount) as TotalCharged, Sum(TaxAmount) as TotalTax, Sum(DiscountAmount) as TotalDiscount
    from RCTE
    Group by MasterChargeID, CustomerID
    GO
    So far so good, I can query this view and get the total cost for a line item including all children.
    The problem occurs when I join this table. The query:
    Select t.* from vwChargeShareSubCharges t
    inner join
    tblChargeShare s
    on t.CustomerID = s.CustomerID
    and t.MasterChargeID = s.ChargeID
    Where s.ChargeID = 1291094
    Takes around 30 ms to return a result (tblCharge and Charge Share have around 3.5 million records).
    But the query:
    Select t.* from vwChargeShareSubCharges t
    inner join
    tblChargeShare s
    on t.CustomerID = s.CustomerID
    and t.MasterChargeID = s.ChargeID
    Where InvoiceID = 1045854
    Takes around 2 minutes to return a result - even though the only charge with that InvoiceID is the same charge as the one used in the previous query.
    The same thing occurs if I do the join in the same query that the CTE is defined in.
    I ran the execution plan for each query. The first (fast) query looks like this:
    The second(slow) query looks like this:
    I am at a loss, and my skills at decoding execution plans to resolve this are lacking.
    I have separate indexes on tblCharge.ChargeID, tblCharge.ParentChargeID, tblChargeShare.ChargeID, tblChargeShare.InvoiceID, tblChargeShare.ChargeShareStatusID
    Any ideas? Tested on SQL 2008R2 and SQL 2012

    >> The database is linked [sic] to an established app and the column and table names can't be changed. <<
    Link? That is a term from pointer chains and network databases, not SQL. I will guess that means the app came back in the old pre-RDBMS days and you are screwed. 
    >> I am not too worried about the money field [sic], this is used for money and money based calculations so the precision and rounding are acceptable at this level. <<
    Field is a COBOL concept; columns are totally different. MONEY is how Sybase mimics the PICTURE clause that puts currency signs, commas, period, etc in a COBOL money field. 
    Using more than one operation (multiplication or division) on money columns will produce severe rounding errors. A simple way to visualize money arithmetic is to place a ROUND() function calls after 
    every operation. For example,
    Amount = (Portion / total_amt) * gross_amt
    can be rewritten using money arithmetic as:
    Amount = ROUND(ROUND(Portion/total_amt, 4) * 
    gross_amt, 4)
    Rounding to four decimal places might not seem an 
    issue, until the numbers you are using are greater 
    than 10,000. 
    BEGIN
    DECLARE @gross_amt MONEY,
     @total_amt MONEY,
     @my_part MONEY,
     @money_result MONEY,
     @float_result FLOAT,
     @all_floats FLOAT;
     SET @gross_amt = 55294.72;
     SET @total_amt = 7328.75;
     SET @my_part = 1793.33;
     SET @money_result = (@my_part / @total_amt) * 
    @gross_amt;
     SET @float_result = (@my_part / @total_amt) * 
    @gross_amt;
     SET @Retult3 = (CAST(@my_part AS FLOAT)
     / CAST( @total_amt AS FLOAT))
     * CAST(FLOAT, @gross_amt AS FLOAT);
     SELECT @money_result, @float_result, @all_floats;
    END;
    @money_result = 13525.09 -- incorrect
    @float_result = 13525.0885 -- incorrect
    @all_floats = 13530.5038673171 -- correct, with a -
    5.42 error 
    >> The keys are ChargeID(int, identity) and ChargeShareID(int, identity). <<
    Sorry, but IDENTITY is not relational and cannot be a key by definition. But it sure works just like a record number in your old COBOL file system. 
    >> .. these need to be int so that they are assigned by the database and unique. <<
    No, the data type of a key is not determined by physical storage, but by logical design. IDENTITY is the number of a parking space in a garage; a VIN is how you identify the automobile. 
    >> What would you recommend I use as keys? <<
    I do not know. I have no specs and without that, I cannot pull a Kabbalah number from the hardware. Your magic numbers can identify Squids, Automobile or Lady Gaga! I would ask the accounting department how they identify a charge. 
    >> Charge_Share_Status_ID links [sic] to another table which contains the name, formatting [sic] and other information [sic] or a charge share's status, so it is both an Id and a status. <<
    More pointer chains! Formatting? Unh? In RDBMS, we use a tiered architecture. That means display formatting is in a presentation layer. A properly created table has cohesion – it does one and only one data element. A status is a state of being that applies
    to an entity over a period time (think employment, marriage, etc. status if that is too abstract). 
    An identifier is based on the Law of Identity from formal logic “To be is to be something in particular” or “A is A” informally. There is no entity here! The Charge_Share_Status table should have the encoded values for a status and perhaps a description if
    they are unclear. If the list of values is clear, short and static, then use a CHECK() constraint. 
    On a scale from 1 to 10, what color is your favorite letter of the alphabet? Yes, this is literally that silly and wrong. 
    >> I understand what a CTE is; is there a better way to sum all children for a parent hierarchy? <<
    There are many ways to represent a tree or hierarchy in SQL.  This is called an adjacency list model and it looks like this:
    CREATE TABLE OrgChart 
    (emp_name CHAR(10) NOT NULL PRIMARY KEY, 
     boss_emp_name CHAR(10) REFERENCES OrgChart(emp_name), 
     salary_amt DECIMAL(6,2) DEFAULT 100.00 NOT NULL,
     << horrible cycle constraints >>);
    OrgChart 
    emp_name  boss_emp_name  salary_amt 
    ==============================
    'Albert'    NULL    1000.00
    'Bert'    'Albert'   900.00
    'Chuck'   'Albert'   900.00
    'Donna'   'Chuck'    800.00
    'Eddie'   'Chuck'    700.00
    'Fred'    'Chuck'    600.00
    This approach will wind up with really ugly code -- CTEs hiding recursive procedures, horrible cycle prevention code, etc.  The root of your problem is not knowing that rows are not records, that SQL uses sets and trying to fake pointer chains with some
    vague, magical non-relational "id".  
    This matches the way we did it in old file systems with pointer chains.  Non-RDBMS programmers are comfortable with it because it looks familiar -- it looks like records and not rows.  
    Another way of representing trees is to show them as nested sets. 
    Since SQL is a set oriented language, this is a better model than the usual adjacency list approach you see in most text books. Let us define a simple OrgChart table like this.
    CREATE TABLE OrgChart 
    (emp_name CHAR(10) NOT NULL PRIMARY KEY, 
     lft INTEGER NOT NULL UNIQUE CHECK (lft > 0), 
     rgt INTEGER NOT NULL UNIQUE CHECK (rgt > 1),
      CONSTRAINT order_okay CHECK (lft < rgt));
    OrgChart 
    emp_name         lft rgt 
    ======================
    'Albert'      1   12 
    'Bert'        2    3 
    'Chuck'       4   11 
    'Donna'       5    6 
    'Eddie'       7    8 
    'Fred'        9   10 
    The (lft, rgt) pairs are like tags in a mark-up language, or parens in algebra, BEGIN-END blocks in Algol-family programming languages, etc. -- they bracket a sub-set.  This is a set-oriented approach to trees in a set-oriented language. 
    The organizational chart would look like this as a directed graph:
                Albert (1, 12)
        Bert (2, 3)    Chuck (4, 11)
                       /    |   \
                     /      |     \
                   /        |       \
                 /          |         \
            Donna (5, 6) Eddie (7, 8) Fred (9, 10)
    The adjacency list table is denormalized in several ways. We are modeling both the Personnel and the Organizational chart in one table. But for the sake of saving space, pretend that the names are job titles and that we have another table which describes the
    Personnel that hold those positions.
    Another problem with the adjacency list model is that the boss_emp_name and employee columns are the same kind of thing (i.e. identifiers of personnel), and therefore should be shown in only one column in a normalized table.  To prove that this is not
    normalized, assume that "Chuck" changes his name to "Charles"; you have to change his name in both columns and several places. The defining characteristic of a normalized table is that you have one fact, one place, one time.
    The final problem is that the adjacency list model does not model subordination. Authority flows downhill in a hierarchy, but If I fire Chuck, I disconnect all of his subordinates from Albert. There are situations (i.e. water pipes) where this is true, but
    that is not the expected situation in this case.
    To show a tree as nested sets, replace the nodes with ovals, and then nest subordinate ovals inside each other. The root will be the largest oval and will contain every other node.  The leaf nodes will be the innermost ovals with nothing else inside them
    and the nesting will show the hierarchical relationship. The (lft, rgt) columns (I cannot use the reserved words LEFT and RIGHT in SQL) are what show the nesting. This is like XML, HTML or parentheses. 
    At this point, the boss_emp_name column is both redundant and denormalized, so it can be dropped. Also, note that the tree structure can be kept in one table and all the information about a node can be put in a second table and they can be joined on employee
    number for queries.
    To convert the graph into a nested sets model think of a little worm crawling along the tree. The worm starts at the top, the root, makes a complete trip around the tree. When he comes to a node, he puts a number in the cell on the side that he is visiting
    and increments his counter.  Each node will get two numbers, one of the right side and one for the left. Computer Science majors will recognize this as a modified preorder tree traversal algorithm. Finally, drop the unneeded OrgChart.boss_emp_name column
    which used to represent the edges of a graph.
    This has some predictable results that we can use for building queries.  The root is always (left = 1, right = 2 * (SELECT COUNT(*) FROM TreeTable)); leaf nodes always have (left + 1 = right); subtrees are defined by the BETWEEN predicate; etc. Here are
    two common queries which can be used to build others:
    1. An employee and all their Supervisors, no matter how deep the tree.
     SELECT O2.*
       FROM OrgChart AS O1, OrgChart AS O2
      WHERE O1.lft BETWEEN O2.lft AND O2.rgt
        AND O1.emp_name = :in_emp_name;
    2. The employee and all their subordinates. There is a nice symmetry here.
     SELECT O1.*
       FROM OrgChart AS O1, OrgChart AS O2
      WHERE O1.lft BETWEEN O2.lft AND O2.rgt
        AND O2.emp_name = :in_emp_name;
    3. Add a GROUP BY and aggregate functions to these basic queries and you have hierarchical reports. For example, the total salaries which each employee controls:
     SELECT O2.emp_name, SUM(S1.salary_amt)
       FROM OrgChart AS O1, OrgChart AS O2,
            Salaries AS S1
      WHERE O1.lft BETWEEN O2.lft AND O2.rgt
        AND S1.emp_name = O2.emp_name 
       GROUP BY O2.emp_name;
    4. To find the level and the size of the subtree rooted at each emp_name, so you can print the tree as an indented listing. 
    SELECT O1.emp_name, 
       SUM(CASE WHEN O2.lft BETWEEN O1.lft AND O1.rgt 
       THEN O2.sale_amt ELSE 0.00 END) AS sale_amt_tot,
       SUM(CASE WHEN O2.lft BETWEEN O1.lft AND O1.rgt 
       THEN 1 ELSE 0 END) AS subtree_size,
       SUM(CASE WHEN O1.lft BETWEEN O2.lft AND O2.rgt
       THEN 1 ELSE 0 END) AS lvl
      FROM OrgChart AS O1, OrgChart AS O2
     GROUP BY O1.emp_name;
    5. The nested set model has an implied ordering of siblings which the adjacency list model does not. To insert a new node, G1, under part G.  We can insert one node at a time like this:
    BEGIN ATOMIC
    DECLARE rightmost_spread INTEGER;
    SET rightmost_spread 
        = (SELECT rgt 
             FROM Frammis 
            WHERE part = 'G');
    UPDATE Frammis
       SET lft = CASE WHEN lft > rightmost_spread
                      THEN lft + 2
                      ELSE lft END,
           rgt = CASE WHEN rgt >= rightmost_spread
                      THEN rgt + 2
                      ELSE rgt END
     WHERE rgt >= rightmost_spread;
     INSERT INTO Frammis (part, lft, rgt)
     VALUES ('G1', rightmost_spread, (rightmost_spread + 1));
     COMMIT WORK;
    END;
    The idea is to spread the (lft, rgt) numbers after the youngest child of the parent, G in this case, over by two to make room for the new addition, G1.  This procedure will add the new node to the rightmost child position, which helps to preserve the idea
    of an age order among the siblings.
    6. To convert a nested sets model into an adjacency list model:
    SELECT B.emp_name AS boss_emp_name, E.emp_name
      FROM OrgChart AS E
           LEFT OUTER JOIN
           OrgChart AS B
           ON B.lft
              = (SELECT MAX(lft)
                   FROM OrgChart AS S
                  WHERE E.lft > S.lft
                    AND E.lft < S.rgt);
    7. To find the immediate parent of a node: 
    SELECT MAX(P2.lft), MIN(P2.rgt)
      FROM Personnel AS P1, Personnel AS P2
     WHERE P1.lft BETWEEN P2.lft AND P2.rgt 
       AND P1.emp_name = @my_emp_name;
    I have a book on TREES & HIERARCHIES IN SQL which you can get at Amazon.com right now. It has a lot of other programming idioms for nested sets, like levels, structural comparisons, re-arrangement procedures, etc. 
    --CELKO-- Books in Celko Series for Morgan-Kaufmann Publishing: Analytics and OLAP in SQL / Data and Databases: Concepts in Practice Data / Measurements and Standards in SQL SQL for Smarties / SQL Programming Style / SQL Puzzles and Answers / Thinking
    in Sets / Trees and Hierarchies in SQL

  • Performance problem with inner join

    Hi
    With this Query
    SELECT *
    FROM TABLE1
    INNER JOIN TABLE2
    ON TABLE1.Col1 = TABLE2.Col2 AND TABLE1.Col2 = TABLE2.Col2
    WHERE TABLE1.Col3 = 'AB' AND
    TABLE2.Col4 = 'ZZ';
    TABLE1 have 6,000,000 of records
    TABLE2 have 9,000,000 of records
    when I run this query the result take 30 secs
    If I change the Optimizer_mode for 'RULE'
    the result take 4 secs
    All statistics is ok
    Primary Key exists for TABLE1 and TABLE2 base-on Col1 and Col2
    And index on Table1.Col3,Table1.Col4
    somebody can help me ?

    Analyze tables compute statistics
    and analyze index compute statistics
    I join explain plan
    STATEMENT_ID TIMESTAMP REMARKS OPERATION OPTIONS OBJECT_NODE OBJECT_OWNER OBJECT_NAME OBJECT_INSTANCE OBJECT_TYPE OPTIMIZER SEARCH_COLUMNS ID PARENT_ID POSITION COST CARDINALITY BYTES
    OTHER_TAG PARTITION_START PARTITION_STOP PARTITION_ID OTHER DISTRIBUTION CPU_COST IO_COST TEMP_SPACE
    WithRule1 2004-01-19 16:28:43 SELECT STATEMENT RULE 0
    WithRule1 2004-01-19 16:28:43 SORT AGGREGATE 1 0 1
    WithRule1 2004-01-19 16:28:43 NESTED LOOPS 2 1 1
    WithRule1 2004-01-19 16:28:43 TABLE ACCESS BY INDEX ROWID MICRODEV T088_INSC 1 ANALYZED 3 2 1
    WithRule1 2004-01-19 16:28:43 INDEX RANGE SCAN MICRODEV IX4_T088_INSC NON-UNIQUE ANALYZED 2 4 3 1
    WithRule1 2004-01-19 16:28:43 TABLE ACCESS BY INDEX ROWID MICRODEV T090_CPOS_DEM 2 ANALYZED 5 2 2
    WithRule1 2004-01-19 16:28:43 INDEX UNIQUE SCAN MICRODEV PK_T090_CPOS_DEM UNIQUE ANALYZED 2 6 5 1
    7 rows selected.
    STATEMENT_ID TIMESTAMP REMARKS OPERATION OPTIONS OBJECT_NODE OBJECT_OWNER OBJECT_NAME OBJECT_INSTANCE OBJECT_TYPE OPTIMIZER SEARCH_COLUMNS ID PARENT_ID POSITION COST CARDINALITY BYTES
    OTHER_TAG PARTITION_START PARTITION_STOP PARTITION_ID OTHER DISTRIBUTION CPU_COST IO_COST TEMP_SPACE
    WithChoose1 2004-01-19 16:29:37 SELECT STATEMENT CHOOSE 0 21680 21680 1 40
    21680
    WithChoose1 2004-01-19 16:29:37 SORT AGGREGATE 1 0 1 1 40
    WithChoose1 2004-01-19 16:29:37 HASH JOIN 2 1 1 21680 59050 2362000
    21680 3875000
    WithChoose1 2004-01-19 16:29:37 TABLE ACCESS BY INDEX ROWID MICRODEV T088_INSC 1 ANALYZED 3 2 1 7031 96727 2708356
    7031
    WithChoose1 2004-01-19 16:29:37 INDEX RANGE SCAN MICRODEV IX4_T088_INSC NON-UNIQUE ANALYZED 2 4 3 1 232 96727
    232
    WithChoose1 2004-01-19 16:29:37 TABLE ACCESS FULL MICRODEV T090_CPOS_DEM 2 ANALYZED 5 2 2 11224 5662693 67952316
    11224
    6 rows selected.

  • Nested loop join v/s Sort merge

    I have seen that nested loops are better if the inner table is being indexed, because for each outer table row, we are looking for a match in the inner table. But is there any case when optimizer still goes for a nested loop even if there is no index on the inner table. That is my first question ?
    My second question := When doing a sort merge join oracle has to sort both result sets and then merge them. Oracle says that if both the row sets, if already sorted is definately better for performance. Ya thats obvious. But back to my upper question, when there is no index on the inner table, is it the situation when oracle goes for a sort merge join ?

    My response should really have examples but since I do not have any handy I will just say about your first question. If there is no index available from table A to table B yes it is possible a nested loop join may still be used and table B read via full table scan within a nested loop. If table B is very small and consists of only a block or two this may be relatively efficient plan. It is more likely you sould see table B full scanned and the result feed into a hash join, but I have seen the plan you mention.
    Back before hash joins were introduced with 7.3 (if my memory is correct) you would see sort/merge joins used more often than you do now. Generally speaking no index on the join conditions would exist for this option to be chosen.
    If you really want to know why and sometimes what the optimizer is going to do buy Jonathan Lewis's book Cost-Based Oracle Fundamentals. If explains the optimizer in more depth than any other source I know of.
    HTH -- Mark D Powell --

  • Inner join 6 tables

    Hello All,
                 I have query optimization required to optimize query.The query consists of 6 tables inner join.Can anybody tell me which is best to optimize this query.

     Hi Lopez, Following is the message shown when i click on the operator
    Physical Operation                       Nest ed Loops
    Logical Operation                           Left Outer Join
    Estimated Execution Mode           Row
    Estimated Operator Cost                0.0000193(0%)
    Estimated I / O Cost                         0
    Estimated Subtree Cost                   0.0202515
    Estimated CPU Cost                          0.0000192
    Estimated Number of Executions   1
    Estimated Number of Rows             4.59298
    Estimated Row Size                        64B
    Node ID                                                0
    Warnings
     No Join Predicate

  • Performance tuning of select with inner join

    Hi experts,
    I need to improve the performanve in these two big selects, could you give me some tips, please?Thanks!
      SELECT AWBELN BPOSNR ARFBSK AWFDAT ALIFRE AKNUMV
             BZZ_TKNUM BKOWRR BZZ_VSART BZZ_DTABF
             CTKNUM CVSART C~TDLNR
             CDTABF CSHTYP C~SDABW
             DTPNUM DVBELN
             EERDAT EVSTEL EKUNNR EANZPK EBTGEW EGEWEI
             E~LFDAT
         INTO CORRESPONDING FIELDS OF TABLE GT_AGENCY
            FROM WBRK AS A
              INNER JOIN WBRP AS B
                 ON AWBELN = BWBELN AND
                    B~KOWRR EQ ''
              INNER JOIN VTTK AS C
                 ON BZZ_TKNUM = CTKNUM
              INNER JOIN VTTP AS D
                 ON CTKNUM = DTKNUM
              INNER JOIN LIKP AS E
                 ON DVBELN = EVBELN
              WHERE A~WBELN IN SO_WBELN AND
                    A~RFBSK IN SO_RFBSK AND
                    A~WFDAT IN SO_WFDAT AND
                    A~LIFRE IN SO_TDLNR AND
                    B~ZZ_VSART IN SO_VSART AND
                    B~ZZ_DTABF IN SO_DTABF AND
                    C~VSART IN SO_VSART AND
                    D~TKNUM IN SO_REBEL AND
                    D~VBELN IN SO_VBELN AND
                    E~ERDAT IN SO_ERDAT AND
                    E~VSTEL IN SO_VSTEL AND
                    E~KUNNR IN SO_KUNNR.
      SORT GT_AGENCY BY TDLNR VSTEL TKNUM TPNUM VBELN.
      DELETE ADJACENT DUPLICATES FROM GT_AGENCY
      COMPARING TDLNR VSTEL TKNUM TPNUM VBELN.
      IF NOT GT_AGENCY[] IS INITIAL.
        SELECT VFKPTDLNR VFKPFKNUM VFKPFKPOS VFKPKNUMV          VFSIKPOSN VFKPREBEL VFSIVBELN vfsivbtyp
          INTO corresponding fields of TABLE GT_SHIPCOST
          FROM VFKP
          JOIN VFSI ON VFSIKNUMV = VFKPKNUMV
          WHERE VFKP~TDLNR IN SO_TDLNR
             AND VFKP~FKNUM IN SO_FKNUM
             AND VFKP~FKPOS IN SO_FKPOS
             AND VFKP~STBER IN SO_STBER
           AND VFKP~FKPTY IN SO_FKPTY
           AND ( VFSI~VBTYP = 'J'(S01) OR
                 VFSI~VBTYP = 'T'(S03) or
                 vfsi~vbtyp = 'a' ).
      ENDIF.
    Thanks a lot!
    Patricia

    Hi
    1) Dont use nested seelct statement
    2) If possible use for all entries in addition
    3) In the where addition make sure you give all the primary key
    4) Use Index for the selection criteria.
    5) You can also use inner joins
    6) You can try to put the data from the first select statement into an Itab and then in order to select the data from the second table use for all entries in.
    7) Use the runtime analysis SE30 and SQL Trace (ST05) to identify the performance and also to identify where the load is heavy, so that you can change the code accordingly
    https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/5d0db4c9-0e01-0010-b68f-9b1408d5f234
    1. Use Inner Joins
    2. INTO TABLE
    3. No nested loop
    4. FOR ALL ENTRIES
    5. Use as much of the key as possible
    5. try to use primary or secondary keys in where condition. When using key fields, start with first key field.
    6. Select only the fields you need for display/processing - avoid select *
    Reward if useful
    regards
    Anji

  • Performance difference between left outer join / inner join

    Hi,
    I've got a complex query which among other things accesses quite a large table. If I use inner join to join this table, the response is quite fast and execution plan shows it uses nested loops to gather the data.
    If I change inner join to left outer join, I get a big performance drop. Cost of query goes from 1441 to 28544.
    I don't uderstand why there's such a difference. For inner join, database has to remove all the rows that don't have match in inner-joined table. For left join it can keep all records and just return NULL values for records that don't have a match. In my mind left join should be faster, as it seems simpler. And the access plan could be the same, couldn't it?
    Execution plan for inner join:
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 288 | 1441 (1)| 00:00:18 |
    | 1 | HASH GROUP BY | | 1 | 288 | 1441 (1)| 00:00:18 |
    | 2 | NESTED LOOPS OUTER | | 1 | 288 | 1440 (1)| 00:00:18 |
    | 3 | NESTED LOOPS | | 1 | 261 | 1438 (1)| 00:00:18 |
    | 4 | NESTED LOOPS | | 318 | 74412 | 508 (1)| 00:00:07 |
    | 5 | NESTED LOOPS | | 318 | 51834 | 189 (0)| 00:00:03 |
    | 6 | TABLE ACCESS BY INDEX ROWID| RESURCE | 1 | 106 | 1 (0)| 00:00:01 |
    |* 7 | INDEX UNIQUE SCAN | RESURCE_PRINCIPAL_NAME_INDEX | 1 | | 0 (0)| 00:00:01 |
    | 8 | TABLE ACCESS BY INDEX ROWID| TASK_USES_RESURCE | 318 | 18126 | 188 (0)| 00:00:03 |
    |* 9 | INDEX RANGE SCAN | TASK_USES_RESUR_IDX$$_0CDC0002 | 318 | | 3 (0)| 00:00:01 |
    | 10 | TABLE ACCESS BY INDEX ROWID | TASK | 1 | 71 | 1 (0)| 00:00:01 |
    |* 11 | INDEX UNIQUE SCAN | TASK_PK | 1 | | 0 (0)| 00:00:01 |
    | 12 | TABLE ACCESS BY INDEX ROWID | TASK_WORK_HISTORY | 1 | 27 | 3 (0)| 00:00:01 |
    |* 13 | INDEX RANGE SCAN | TASK_WORK_HISTORY_INDEX1 | 1 | | 2 (0)| 00:00:01 |
    | 14 | TABLE ACCESS BY INDEX ROWID | TASK_USES_RESURCE | 1 | 27 | 2 (0)| 00:00:01 |
    |* 15 | INDEX UNIQUE SCAN | TASK_USES_RESURCE_UK1 | 1 | | 1 (0)| 00:00:01 |
    For left outer join:
    | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 318 | 1596K| | 28544 (2)| 00:05:43 |
    |* 1 | HASH JOIN OUTER | | 318 | 1596K| 1584K| 28544 (2)| 00:05:43 |
    | 2 | VIEW | | 318 | 1580K| | 508 (1)| 00:00:07 |
    | 3 | NESTED LOOPS | | 318 | 74412 | | 508 (1)| 00:00:07 |
    | 4 | NESTED LOOPS | | 318 | 51834 | | 189 (0)| 00:00:03 |
    | 5 | TABLE ACCESS BY INDEX ROWID| RESURCE | 1 | 106 | | 1 (0)| 00:00:01 |
    |* 6 | INDEX UNIQUE SCAN | RESURCE_PRINCIPAL_NAME_INDEX | 1 | | | 0 (0)| 00:00:01 |
    | 7 | TABLE ACCESS BY INDEX ROWID| TASK_USES_RESURCE | 318 | 18126 | | 188 (0)| 00:00:03 |
    |* 8 | INDEX RANGE SCAN | TASK_USES_RESUR_IDX$$_0CDC0002 | 318 | | | 3 (0)| 00:00:01 |
    | 9 | TABLE ACCESS BY INDEX ROWID | TASK | 1 | 71 | | 1 (0)| 00:00:01 |
    |* 10 | INDEX UNIQUE SCAN | TASK_PK | 1 | | | 0 (0)| 00:00:01 |
    | 11 | VIEW | | 1480K| 73M| | 23431 (2)| 00:04:42 |
    |* 12 | HASH JOIN RIGHT OUTER | | 1480K| 76M| 38M| 23431 (2)| 00:04:42 |
    | 13 | TABLE ACCESS FULL | TASK_USES_RESURCE | 1486K| 21M| | 2938 (2)| 00:00:36 |
    | 14 | VIEW | | 1445K| 53M| | 15031 (2)| 00:03:01 |
    | 15 | HASH GROUP BY | | 1445K| 37M| 110M| 15031 (2)| 00:03:01 |
    | 16 | TABLE ACCESS FULL | TASK_WORK_HISTORY | 1445K| 37M| | 3897 (2)| 00:00:47 |
    --------------------------------------------------------------------------------------------------------------------------

    ...continued
    Complete execution plan for left join:
    | Id  | Operation                       | Name                           | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |                                                                                                                                                                                  
    |   0 | SELECT STATEMENT                |                                |   318 |  1594K|       | 28544   (2)| 00:05:43 |                                                                                                                                                                                  
    |*  1 |  HASH JOIN OUTER                |                                |   318 |  1594K|  1584K| 28544   (2)| 00:05:43 |                                                                                                                                                                                  
    |   2 |   VIEW                          |                                |   318 |  1578K|       |   508   (1)| 00:00:07 |                                                                                                                                                                                  
    |   3 |    NESTED LOOPS                 |                                |   318 | 74412 |       |   508   (1)| 00:00:07 |                                                                                                                                                                                  
    |   4 |     NESTED LOOPS                |                                |   318 | 51834 |       |   189   (0)| 00:00:03 |                                                                                                                                                                                  
    |   5 |      TABLE ACCESS BY INDEX ROWID| RESURCE                        |     1 |   106 |       |     1   (0)| 00:00:01 |                                                                                                                                                                                  
    |*  6 |       INDEX UNIQUE SCAN         | RESURCE_PRINCIPAL_NAME_INDEX   |     1 |       |       |     0   (0)| 00:00:01 |                                                                                                                                                                                  
    |   7 |      TABLE ACCESS BY INDEX ROWID| TASK_USES_RESURCE              |   318 | 18126 |       |   188   (0)| 00:00:03 |                                                                                                                                                                                  
    |*  8 |       INDEX RANGE SCAN          | TASK_USES_RESUR_IDX$$_0CDC0002 |   318 |       |       |     3   (0)| 00:00:01 |                                                                                                                                                                                  
    |   9 |     TABLE ACCESS BY INDEX ROWID | TASK                           |     1 |    71 |       |     1   (0)| 00:00:01 |                                                                                                                                                                                  
    |* 10 |      INDEX UNIQUE SCAN          | TASK_PK                        |     1 |       |       |     0   (0)| 00:00:01 |                                                                                                                                                                                  
    |  11 |   VIEW                          |                                |  1480K|    73M|       | 23431   (2)| 00:04:42 |                                                                                                                                                                                  
    |* 12 |    HASH JOIN RIGHT OUTER        |                                |  1480K|    76M|    38M| 23431   (2)| 00:04:42 |                                                                                                                                                                                  
    |  13 |     TABLE ACCESS FULL           | TASK_USES_RESURCE              |  1486K|    21M|       |  2938   (2)| 00:00:36 |                                                                                                                                                                                  
    |  14 |     VIEW                        |                                |  1445K|    53M|       | 15031   (2)| 00:03:01 |                                                                                                                                                                                  
    |  15 |      HASH GROUP BY              |                                |  1445K|    37M|   110M| 15031   (2)| 00:03:01 |                                                                                                                                                                                  
    |  16 |       TABLE ACCESS FULL         | TASK_WORK_HISTORY              |  1445K|    37M|       |  3897   (2)| 00:00:47 |                                                                                                                                                                                  
    Query Block Name / Object Alias (identified by operation id):                                                                                                                                                                                                                                               
       1 - SEL$1AFB0324                                                                                                                                                                                                                                                                                         
       2 - SEL$58A6D7F6 / from$_subquery$_005@SEL$8                                                                                                                                                                                                                                                             
       3 - SEL$58A6D7F6                                                                                                                                                                                                                                                                                         
       5 - SEL$58A6D7F6 / RESURCEWORKER@SEL$2                                                                                                                                                                                                                                                                   
       6 - SEL$58A6D7F6 / RESURCEWORKER@SEL$2                                                                                                                                                                                                                                                                   
       7 - SEL$58A6D7F6 / TASKUSESRESURCE@SEL$1                                                                                                                                                                                                                                                                 
       8 - SEL$58A6D7F6 / TASKUSESRESURCE@SEL$1                                                                                                                                                                                                                                                                 
       9 - SEL$58A6D7F6 / TASK@SEL$1                                                                                                                                                                                                                                                                            
      10 - SEL$58A6D7F6 / TASK@SEL$1                                                                                                                                                                                                                                                                            
      11 - SEL$7EBCC247 / TRW@SEL$3                                                                                                                                                                                                                                                                             
      12 - SEL$7EBCC247                                                                                                                                                                                                                                                                                         
      13 - SEL$7EBCC247 / TUR@SEL$4                                                                                                                                                                                                                                                                             
      14 - SEL$6        / TRW_IN@SEL$5                                                                                                                                                                                                                                                                          
      15 - SEL$6                                                                                                                                                                                                                                                                                                
      16 - SEL$6        / TWH@SEL$6                                                                                                                                                                                                                                                                             
    Predicate Information (identified by operation id):                                                                                                                                                                                                                                                         
       1 - access("TRW"."RESURCE_ID"(+)="TASKUSESRESURCE"."RESURCE_ID" AND "TRW"."TASK_ID"(+)="TASK"."ID")                                                                                                                                                                                                      
       6 - access("RESURCEWORKER"."USER_PRINCIPAL_NAME"=U'jernej')                                                                                                                                                                                                                                              
       8 - access("TASKUSESRESURCE"."RESURCE_ID"="RESURCEWORKER"."ID")                                                                                                                                                                                                                                          
      10 - access("TASKUSESRESURCE"."TASK_ID"="TASK"."ID")                                                                                                                                                                                                                                                      
      12 - access("TUR"."RESURCE_ID"(+)="TRW_IN"."RESURCE_ID" AND "TUR"."TASK_ID"(+)="TRW_IN"."TASK_ID")                                                                                                                                                                                                         Jonathan, I've been to one of your workshops in Ljubljana. I'm still trying to understand everything you explained and use it, but there's much I have to learn and understand.
    The way I see this query it should fist join and filter the first three tables and only then join the trw subquery. The problem with this subqrey is task_work_history table, which is accessed in very different ways in different places, so there will always be many reads to gather required data. For now, however, I'd be hapy to just bring the performance of inner join to left join...

  • When does oracle use a complete nested loop join?

    Hi!
    Does Oracle Database use a complete nested loop join? I mean, imagine 2 tables without any indexes.. is there any case where for each row in the outer table Oracle does a complete scan in the inner table? I know that this is the original algorithm for the nested loop join, but some data bases prefer to make a temp table to autoindex the inner table and never makes the complete scan in the inner table..
    thanks!!

    user12040235 wrote:
    If the table do not have indexes.. some data bases prefer to scan one time the inner table, to index all values, and than, for every row in the outter loop table, it will do a index search.
    I just like to know oracle does the same thing, or it does the complete scan..If you have two tables without indexes, Oracle may consider scanning one table, extracting the smallest data set it can get away with, and then building a hash table of that data set (rather than creating an in-memory copy with index). At this point Oracle can then do a nested loop join into the in-memory hash table.
    However, this is called a hash join, and the order of tables will appear to be reversed, viz:
    nested loop
        table scan full ABC
        table scan full XYZ
    {code]
    becomeshash join
    table scan full XYZ
    table scan full ABC
    See: http://jonathanlewis.wordpress.com/2010/08/02/joins/ as a starting point if you want to read more on this topic.
    Regards
    Jonathan Lewis                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

  • Problem in Accession inner join with [Microsoft][SQLServer 2000 Driver

    Hi
    Can you tell me what can be cause my sql statement is correct gives result but
    if i used below statement in my JSP ,cause error
    1)
    ps1=connection.prepareStatement("select RQM_IN_RQSTN_ID_PK,RQD_IN_ITM_ID_FKPK,RQD_VC_ITM_DSCRPTN,RQD_IN_STTS_ID_FK,C.SMT_VC_STTS_NM,a.RQM_DT_PRPSD_DLVRY_DT"+
    "from PAS_RQM_RQSTN_MSTR a "+
    "inner join PAS_RQD_RQSTN_DTLS b on a.RQM_IN_RQSTN_ID_PK = b.RQD_IN_RQSTN_ID_FKPK and RQD_IN_STTS_ID_FK = 4"+
    "INNER JOIN PAS_SMT_STTS_MSTR C ON C.SMT_IN_STTS_ID_PK=B.RQD_IN_STTS_ID_FK" +
    "where a.RQM_VC_DTRTMNT_INVLV='Technology' ");
    2) Error Generate
    java.sql.SQLException
    [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]Line 1: Incorrect syntax near 'a'.
    What can be the cause
    Thanks

    ps1=connection.prepareStatement("select
    RQM_IN_RQSTN_ID_PK,RQD_IN_ITM_ID_FKPK,RQD_VC_ITM_DSCRP
    TN,RQD_IN_STTS_ID_FK,C.SMT_VC_STTS_NM,a.RQM_DT_PRPSD_D
    LVRY_DT"+
    "from PAS_RQM_RQSTN_MSTR a "+
    "inner join PAS_RQD_RQSTN_DTLS b on
    a.RQM_IN_RQSTN_ID_PK = b.RQD_IN_RQSTN_ID_FKPK and
    RQD_IN_STTS_ID_FK = 4"+
    "INNER JOIN PAS_SMT_STTS_MSTR C ON
    C.SMT_IN_STTS_ID_PK=B.RQD_IN_STTS_ID_FK" +
    "where a.RQM_VC_DTRTMNT_INVLV='Technology' ");This is a problem due to not providing spaces where they are needed. See the places where I have highlighted.
    A better way is to generate the String first [use StringBuffer as a good practice for appending instead of String "+"] and print it out to check if it is correct.
    ***Annie***

Maybe you are looking for

  • My iPhoto opens, but doesn't detect or sync any of my iPod camera roll when I connect it to my laptop. How do i fix this?

    So my friend lent me her apple cable to connect to my laptop since my one stopeed working a few weeks ago, and as I tried to sync my iPod touch camera roll to my iPhoto, iPhoto devices came up with "Apple Device" instead of my devices name. And as I

  • Patch List for Self-Service Human Resources (SSHR) in HRMS 11i

    Friends - We are planning to implement Self-Service Human Resources in HRMS 11i. I am able to find out information using metalink note : Recommended Patch List for Self-Service Human Resources (SSHR) in HRMS 11i [ID 108897.1]. As per note : 108897.1

  • Excel Charts import into iweb

    Can you import charts created in excel or charts from financial websites (i.e. daily stock market charts) into iweb? If yes, can you please explain? Thanks

  • Transport from one System to another

    Hello, I want to transport from one XI-System to another XI-System. I tried to make a import from the SLD but that doesn´t work, why? When i make a file transport and make changes of the transported Software-Component will there be the changes of the

  • Call to BPM WebServive and Return BPM GUID

    Hello, When calling the web service to start a BPM process, we would like the web service to return to the calling application the guid of the BPM process that was created. The purpose of this is to provide the calling application a level of traceabi