Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
obook@msn.com
Starting Member
1 Post |
 Posted - 2007-08-13 : 22:48:27
|
| Many places in our code we check if a record exisits first (using a custom function) before performing and update statement. The custom function itself is doing a SQL SELECT statement to return true/false if record exists. So at a minimum, I do one SQL call, if update needed then a second call. Why not just fire off the Update statement( passing the record key). If the record did not exisit, it can not perform the update. If it does, update performed. QUESTION. Is this a bad practice? Is it bad practice to fire update, using the Key field, to a table whether you know the record exisits or not? |
|
|
ValterBorges
Master Smack Fu Yak Hacker
1429 Posts |
Posted - 2007-08-13 : 22:56:06
|
| To me the question is one of performance. Behind the scenes an update is actually doing a delete and an insert that's two operations. If you figure that more than 50% of the time the record doesn't exist then issue an insert and if you detect a failure then issue an update. On the other hand if you determine that most of the time the record exists then do an update and if it fails then perform an insert. If this is really cuts down the time it takes and improves performance and you've already tried using EXISTS (select top 1 *) and indexing then I say it's a valid consideration. |
 |
|
|
|
|
|
Update statement