Thanks - we may need to go down this road... a lot of this slowness could probably be eliminated if we had one field PKs, but unfortunately at this time, not all the lookup tables do.
Kevin -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MB Software Solutions General Account Sent: Wednesday, April 23, 2008 10:47 AM To: [EMAIL PROTECTED] Subject: Re: Looking to optimize a query > Any thoughts on an approach to build this SELECT statement to make it > faster? Unfortunately at this time, we are also forced with the > concatenating of these fields - there is no unique field to pull from. > I'd use the 2nd table as what the person selected...even though it might be more records. I'd use the PK (or combo key) stored as a FK in the 2nd table, then SELECT from the 2nd table, marrying in via JOIN to the first table to grab the relevant info. It may mean storing more records, but it's avoiding the NOT IN scenario, which may be worth it performance-wise! hth, --Michael _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
