Unbest Practices #1 – Comments Full of Awesome
I love seeing good documentation in code. I really love seeing honest documentation in code. Seeing comments that basically show the developer has given up, hacked together a poor workaround to get a tasked accomplished at the cost of performance for every customer… full of Awesome. This is slightly redacted code from a stored procedure that was at the head of a blocking chain on one of my prod servers this weekend:
-- REVIEW
-- Currently processing updates as re-inserts.
-- This is because we don't really have a guaranteed key into
-- this table: the <redacted> key isn't completely sufficient.
-- We might be able to get there by using the <redacted> foreign key as well
-- and tracking that in the @<redacted> table.
-- This also avoids our needing to write the query twice or
-- creating a view to use in the update as well as the insert.So yes, this product performs UPDATEs as explicit DELETEs and INSERTs. I would not be surprised if this was originally coded in purple crayon.
Peoples: take the time to find the answer – not a passable solution. I tell my son’s that and they understand that at the age of 9 and 12.
It took me three reads to understand what you meant because it didn’t make sense.
So every time they needed to do a single update, they would first delete the existing record, then insert a new one. That is amazing. It’s hard work being that bad.
I reminded of an old saying “If it’s worth doing, it’s worth doing right.”
Which is true more often than not.
Eh, whatever. I have development teams that base their entire methodology on the concept of delete everything and reinsert it because, and I quote “That’s how SQL Server does updates anyway.”
If it’s worth doing do it twice! wtf?
“UPDATEs as explicit DELETEs and INSERTs” because you can’t be sure the key is good enough? How do you know you are deleting the correct one then?
Have a current isue like yours but we want to update a column of a compound key and we all know that is a no-go.
This is what happens when non-sql developers develop sql..”how hard can it be?”…….
Been there, seen that. In the cases I’ve seen, it’s usually that the original PK did work before, but the business rules changed, upstream changes were made, things broke, and rather than make the proper schema changes which would impact a much larger set of stuff, pretend the old rules still worked.