This post is for the most recent #tsql2sday, a monthly exercise where a topic is proposed by a community member and everyone is invited to post their thoughts on the subject. This month Rob Volk has asked us “how would you explain database concepts to someone who’s not technologically savvy,” or relatedly, “explain databases like I’m five!”
I’m very excited to participate this month, because, as anyone who has seen my “Faster Transactions” presentation recently knows, I love using the analogy of SQL Server transactions as orders in a restaurant.
Let me tell you briefly about the “Le SQL Server” restaurant.
Kid
Now, I realize that Rob has asked us to “explain this like I am five,” and I fully realize if I start talking about process flow in a restaurant this won’t make much sense to your kindergartner. That is, unless you let your kindergartner watch “Hell’s Kitchen,” in which case I’d say I have a few questions about your parenting choices.
But you, dear reader, I will make the leap of presumption that you have dined in a restaurant or possibly even worked in such an establishment yourself. Not that we go to these things much in 2020, but no bother.
I Go To Sleep
The premise of my entire session is that by possessing a basic understanding what a transaction in SQL Server actually does in terms of using data pages, locks, and the transaction log, a developer can then have a better idea of how to improve the performance of transactions.
This is a bit tricky because in order to do this I have to take a little bit of a dive into the dreaded realm of SQL Server Internals. Just saying the words “SQL Server Internals” makes most of us go into a mini-coma, our eyes glazing over, and our palms becoming sweaty. This is especially true for the audience in my session because they want “faster transactions” and not a dissertation regarding things like log buffer flushes and page-level locks.
I realized this after I made the third slide of my original session a diagram that included these SQL Server things. People were falling asleep by the fourth slide. And by people, I include myself.
So I came up with a restaurant analogy….which I will get to now.
Show Me
This is the main slide I use to show the analogy of an order in a restaurant. It is preceded by some explanatory slides that discuss placing an order with the waiter.
- The waiter writes down the order on their little ticket pad (log buffer cache)
- That order is placed in the ticket queue (transaction log)
- The chef assembles the ingredients at their workstation (data pages in the buffer cache)
- The chef gets any missing ingredients from the pantry (data pages read from disk)
- No other chef can use an ingredient while another chef is using it (locks)
I’ve given this session several times since adding this restaurant analogy, and much to the delight of all no one has fallen asleep. Then again, I haven’t tried presenting the session to five-year-olds.
This sounds cool, the TRANSACTIONs as Food Orders and recently taking 70-762, it has sparked my interest. It seems to be the way, to understand Transactions, which go all the way from internals to SSMS writing queries. And because XactState seems definitive, one, 0 minus1. But it gets confusing to me once multiple users start running, and then I think any transaction that’s unknown completion, I put in CATCH statements, but this is only in development right? Nobody use Try Catch in production code? This analogy could be useful. you might check out, my Robot analogy, And, ha ha, LeSQL, silly French, always confusing and making 5 different versions of the same sauce, no wonder she made a cooking show to explain it. And is Xactstate used a lot in production code? For production, does Xactstate sometimes get into the 1000s for concurrent transactions?