views:

61

answers:

4

Hi,

I have 2 tables one with a lot of records(table 1), and a second(table 2) with similar data but with far fewer records.

On a regular basis i need to add a marker to records in the larger table where there is a corresponding record in the smaller table. For example this could be an email address.

So if email address exists in the smaller table(table 2) mark this in the larger table(table 1)

Now, i know this is a bit vague but the actual data isnt relevant nor is table/column names. What im looking for is ideas / suggestions as the most efficient way to do this.

Do i run a procedure that....

A) checks a record in one table and then looks for a corresponding record in the other? Then marks this record if it has a match. Which way around is best?

B) Do something with temporary tables?

c) something totaly different? Please give pointers.

I hope this makes sense, and i hope you can help.

Thanks!

+6  A: 

Do an UPDATE that consists of an INNER JOIN between the two tables on email address.

Mitch Wheat
Good idea, but i wouldnt have known how without CJM's example. Thanks ;-)
Munklefish
+1  A: 

Since you are on SQL 2005, you cannot use the MERGE command. You have to use an INSERT and an UPDATE statement to do this.

Once you write the SQL to do this, you can create a SQL Job that executes this statement periodically and schedule it.

Here is how to schedule a job: http://msdn.microsoft.com/en-us/library/ms190268.aspx

Raj More
Raj, Thanks for that. I already know about scheduling and it seriously is useful.
Munklefish
+2  A: 

Roughly speaking, do something like this:

Update LargeTable
Set Marker = 1
From LargeTable l
inner join SmallTable s
on s.ID = l.ID
Where s.SomeField = 'Criteria'
CJM
Hmmm! Excellent suggestion thanks. Seems like a very efficient method (from my limited knowledge) ;-)
Munklefish
you should be consistent with your use of aliases, _UPDATE l SET l.Marker=1 FROM LargeTable l INNER JOIN_....
KM
@KM - there is no need for an alias in the SET statement, since it can only apply to the target of the UPDATE statement. If there is no ambiguity, there is no need for clarification. Clearly, your suggestion does no harm, but equally I personally see no benefit.
CJM
+1  A: 

Why not create a trigger that will automatically update the first table when a record is put into, delted from or changed in the second table. Or better yet,, why not just join to the second table when you want to know this information instead of denormailzing to store in the first?

HLGEM
There are often cases for denormalisation (to some extent or other), but in general I think you make good points.
CJM
Anytime you denormalize like this you need to set up a trigger to make sure the data stays in synch. or else one table willhave stale data.
HLGEM
either table can be updated at any time hence the issue. Any suggestions on how triggers would help would be appreciated. Thanks.
Munklefish
Either table being updated is a problem with the design. The data should only be allowed to change in one table and the trigger will automatically change the other. Otherwise you could get into an eternal loop.
HLGEM