Re: Join Table

Ronald, I believe set processing is significantly faster than cursor processing in SQL Server as well as most other DBMSs. The exception to this rule is if the optimizer generates a poor execution plan.

However, I do agree with your statement that joins can be difficult to read and understand. Most folks, especially programmers, have a tendency to take a procedural approach in retrieving data. However, the performance benefits make learning 'pure SQL with the trouble. This is especially true for large applications.

BTW, I think either of the following queries address Ng K C Paul's issue:

    SELECT tab1_key, tab2_key
    FROM tab1, tab2
    WHERE tab2_key = (SELECT MAX(tab2_key) FROM tab2 WHERE tab2_key <= tab1_key)

    SELECT tab1_key, tab2_key
    FROM tab1
    JOIN tab2 ON tab2_key = (SELECT MAX(tab2_key) FROM tab2 WHERE tab2_key <= tab1_key)

Roland Svensson wrote in message <3615dba6.7453998_at_nntpserver.swip.net>...
>On 29 Sep 1998 10:40:27 GMT, paulkcng_at_news.netvigator.com (Ng K C
>Paul) wrote:
>
>>From the performance point of view, should I use cursor instead of
>>joining table to select data?
>>
>Yes, and not only from the performance point of view. Your task
>is quite easily solved by two cursors and some matching code.
>A 'pure' SQL solution performs terrible and is hard to read
>and understand.
>
>--
>Regards,
>Roland
Received on Sat Oct 03 1998 - 00:00:00 CDT