Whenever we have to update the database; we delete the values from the table first and then add the latest values. This ensures that everything is updated correctly.
This adds little bit overhead to the system but we haven't faced any performance issues because of this.
Is this always the best thing to do?
No.
Use the UPDATE statement.
Additionally, if you worried about integrity, scope it within a transaction:
BEGIN TRAN T1
-- This update is part of T1
UPDATE Table1 SET Col1='New Value' WHERE Col2 = @Id;
-- Time to commit your changes.
-- If for any reason something fails,
-- everything gets rolled back
COMMIT TRAN T1
No.
If the table is indexed (most are) but you don't have a regular index maintenance task running to rebuild (defragment) the index, updating will be preferable. Deleting and recreating rows will lead to fragmentation over time.
By "database" I presume you mean a SQL database. The danger of doing a delete then insert is, unless you're careful with your transactions, it is non-atomic. In the time between deleting the row and inserting the new one someone might have slipped a similar row in causing the insert to fail on some constraint. It's also a waste of effort because there's update, as J. Holland points out. It'll all do it in one shot. Putting it alone in its own transaction is probably unnecessary as updates are atomic.
If you're doing the delete-then-insert because you're not sure if the row already exists, some databases have a replace statement which will insert if there's no row or update if there is.
As everyone else said, use UPDATE.
One extra reason: if you have CASCADE DELETE on any referential integrity constraints, DELETE then INSERT loses the subordinate data. If you don't have CASCADE DELETE, then you may be unable to DELETE the record because it is still referenced by other tables.
A delete-insert is a higher cost operation than an update.
If the reason is not obvious, it is because you have to store undo/redo information for the complete row being removed, including the modification of all index entries and checks for referential integrity violations caused by the deletion, followed by the insert of a new row with all of the undo/redo, index entry, integrity checks etc.. the new row might also be in a different block to the deletion so now you are doubling (at least) the physical i/o requirements.
Also consider the impact on triggers and logging. And you have to grant insert and delete privileges when you could just be granting update privileges.
I'm sure that there is a regular programming paradigm, such as "When I want to assign a new value to a variable, I always set it to zero first ..." but i fear that it wouldn't convey the full horror of the situation.