| < Day Day Up > |
|
Shortcut joins are the best thing since chocolate chip cookies were invented (I know, the cliché is sliced bread, but I still buy whole loaves). Shortcut joins allow you to define an alternative, faster join path between two tables. Prior to shortcut joins, BusinessObjects would often have to go through a huge fact table to create simple reference lists. To the unsuspecting user, this query could take hours (and this was before time estimates existed, as well).
Figure 7-8 shows an example of a shortcut join between the PLANT table and the PRODUCTS table (line 1). If the shortcut join were a normal join, Designer would detect a loop. If you did not define a shortcut join and users wanted a list of which plants made which products, their query would be forced to join three tables together (join lines 2 and 3) and unnecessarily go through the large 30-million-row fact table. The shortcut join is a way of telling BusinessObjects that this is the fastest path to use for queries in which no objects come from the Orders_Fact table. Therefore, if users created a report to determine which suppliers ship to specific plants, the shortcut join is also used.
Figure 7-8: Shortcut joins provide BusinessObjects with an alternate, faster join path without creating a loop.
| < Day Day Up > |
|