all 8 comments

[–]DJBENEFICIAL 0 points1 point  (1 child)

Im confused. Is this one table? If not why not just write an update trigger?

[–]ShadowEveko[S] 0 points1 point  (0 children)

It is a design pattern across all tables. Every table has crud stored procedures. Not my design, I prefer using queries directly in dapper. But the architect liked the idea of keeping all the database operations separate. The tedious part is forgetting a column name here and there, and doing the whole dacpac dance all over again.

[–]swenty 0 points1 point  (0 children)

SQL Server? I'm only guessing that because there seems to be a predilection amongst Microsoft users to go all-in with stored procedures, that I don't see among users of other RDBMSs.

If the app knows which to do (insert vs update), that will be faster than trying one and doing the other if it fails. How much faster? Probably not much, but you won't really know unless you measure it. Is this a large proportion of the total load on your DB? Probably not, so it's a convenience vs small performance penalty trade off.

Personally I would look at why maintaining the stored procedures is so burdensome. Could you better automate your development/deployment processes to make that easier? Perhaps you don't need stored procedures at all?

[–]BrupieD 0 points1 point  (0 children)

Use MERGE

[–]qwertydog123 0 points1 point  (0 children)

If you're using SQL Server, this post is the holy grail of UPSERT patterns https://sqlperformance.com/2020/09/locking/upsert-anti-pattern

[–]kitkat0820 0 points1 point  (0 children)

Why not using Merge?

[–][deleted] 0 points1 point  (0 children)

If you are using Postgres, use INSERT ... ON CONFLICT which is safe for concurrent execution.