Hacker News Reader

Comment by preseinger | Hacker News Reader

you can do that equally well in a stored procedure and a single query

like, you can write a query which does all of these transforms in sequence, and returns the final result set

the data that goes between client and server is only that final result set, it's not like the client receives each intermediate step's results and sends them back again?

View on HN

If you’re going to mix multiple queries with procedural logic — eg running query A vs B depending on whatever conditions based on query C, then a stored proc saves you the round trips versus doing it in your app code. That’s all he’s saying.

it doesn't! whatever code you put into the stored proc you can equally well put into a query, and the round-trip costs would be equivalent

a stored proc is just a query saved on the db server, nothing more

if you destructure a stored proc to multiple individual queries, ok, sure, but who would do that?

It seems you don't have a lot of experience or understanding regarding stored procedures.

Obviously if you just take a single query and turn it into a stored procedure then yes, the round-trip cost is the same. This seems to be where your knowledge ends. Perhaps we can expand that a bit.

Let's look at a more involved example with procedural logic. This would be many, many round trips.

https://www.red-gate.com/simple-talk/databases/sql-server/t-...

I'm not exactly endorsing that example. Personally, I would almost never choose to put so much of my application logic into a stored procedure, at least not as a first choice. This is just an example of what's possible and not something I am endorsing as a general purpose best practice.

With that caveat in mind, what's shown there is going to be pretty performant compared to a bunch of round trips. Especially if you consider something like that might need to be wrapped in a transaction that is going to block other operations.

Also, while you may be balking at that primitive T-SQL, remember that you can write stored procedures in modern languages like Python.

https://docs.snowflake.com/en/sql-reference/stored-procedure...

good lord man, the condescension is so thick and rich, it's like i'm reading an eclair, and the eclair is insulting me based on its own misunderstanding of the topic of conversation

powerful stuff

That'll happen when you're publicly and confidently wrong. If you scroll up, you'll find any number of posts where folks pointed out your misconceptions in a more kindly fashion. When we factor in the fact that you're wrong (as opposed to my post which is correct, informative, and cites examples) I think many would say your incorrect assertions are a lot ruder and less HN-worthy.

Sometimes folks know more about a given thing than you do. That is okay. The goal is to learn. I am sure you know more than I do about zillions of things. In fact, that is why I come here. People here know things.

haha, man, the absolute _chutzpah_ you need to make (incorrect) accusations like this, even as an anonymous person on the internet, is really breathtaking

i hope you reflect on this interaction at some point

You seem to be firm in your objectively wrong belief that:

    a stored proc is just a query saved on the db server, nothing more

Absolutely not. They can contain procedural logic as well. You can do a wide range of things in a stored proc that are far beyond what can be done with a query. Again.... I provided some links with examples. You don't need to believe me.

    i hope you reflect on this interaction at some point

Wow.

If you're just writing a single access app for a DB I agree it doesn't really matter much. Where SPs really help is when you're maintaining a DB that multiple projects from multiple teams access and you can present them a single high-level API to use, so that Accounting and Fulfillment aren't reinventing the same wheels over and over. So it's more about stack management than anything else.

Not, if you consider inserts, updates and deletes in addition to selects.

Not, if you want to spread the queries over multiple transactions.

Reply on news.ycombinator.com