<p>I've written a stored proc that will do an update if a record exists, otherwise it will do an insert. It looks something like this:</p>

<pre><code>update myTable set Col1=@col1, Col2=@col2 where ID=@ID
if @@rowcount = 0
insert into myTable (Col1, Col2) values (@col1, @col2)
</code></pre>

<p>My logic behind writing it in this way is that the update will perform an implicit select using the where clause and if that returns 0 then the insert will take place.</p>

<p>The alternative to doing it this way would be to do a select and then based on the number of rows returned either do an update or insert. This I considered inefficient because if you are to do an update it will cause 2 selects (the first explicit select call and the second implicit in the where of the update). If the proc were to do an insert then there'd be no difference in efficiency.</p>

<p>Is my logic sound here?
Is this how you would combine an insert and update into a stored proc?</p>

Your assumption is right, this is the optimal way to do it and it's called
upsert/merge
.
Importance of UPSERT - from sqlservercentral.com
:
For every update in the case mentioned above we are removing one
  additional read from the table if we
  use the UPSERT instead of EXISTS.
  Unfortunately for an Insert, both the
  UPSERT and IF EXISTS methods use the
  same number of reads on the table.
  Therefore the check for existence
  should only be done when there is a
  very valid reason to justify the
  additional I/O. The optimized way to
  do things is to make sure that you
  have little reads as possible on the
  DB.
The best strategy is to attempt the
  update. If no rows are affected by the
  update then insert. In most
  circumstances, the row will already
  exist and only one I/O will be
  required.
Edit
: 
Please check out
this answer
and the linked blog post to learn about the problems with this pattern and how to make it work safe.