====== The Ice Cream Van of Abstraction ======

{{tag> blog tsqltuesday frozenfoods}}

[[https://sqlrblog.wordpress.com/2020/10/05/t-sql-tuesday-131-data-analogies-or-explain-databases-like-im-five/|{{:blog:tsql-tuesday.png?nolink&140  }}]]

October 2020's [[http://tsqltuesday.com/|T-SQL Tuesday]] is hosted by Rob Volk ([[https://sqlrblog.wordpress.com/|b]]|[[https://twitter.com/sql_r|t]]) with the subject //Data Analogies, or: Explain Databases Like I’m Five!// Thanks for hosting, Rob! It turns out that I don't do much specifically //databas//plaining™ by analogy, but there's one analogy I go back to again and again when talking to people unfamiliar with a useful concept, both inside and outside of SQL Server: //abstraction//.

===== Abstraction =====
We use abstraction all the time in computing, but a feature I'm frequently trying to communicate is that it introduces useful separation between a //data consumer// and the detail of //how a data producer is implemented//. A use case for this in an ETL environment could be isolating an SSIS package or a SQL stored procedure from an unexpected change to a source table structure -- I've often used a SQL view to achieve this effect.

In this scenario, maybe your ETL batch crashes because a source table structure has changed and you weren't notified in advance 🙄. You're in a hurry to get back up and running, so you want to do as little work as possible to fix the problem. One approach is to create a view that selects data from the new table but outputs it in the old table format -- change the data source from the table to the view and you're good to go. This isn't ideal, but it at least gives you some breathing room to make a fuller or more considered ETL pipeline reimplementation.

The reason this works is that the data consumer doesn't need to care about where data "really" comes from -- table or view -- as long as it presents the same schema((I say "really" because of course the table itself is just a convenient abstraction for data stored on database pages 😀.)). This is the abstraction I'm trying to explain.

===== The Ice Cream Van =====

For anyone who's forgotten how an ice cream van works (it is October, after all), here's a quick refresher:

{{ :blog:ice-cream-van.jpeg?nolink&200|}}

  - Ice cream van pulls up
  - You head over to the window, give the vendor some money
  - Vendor gives you an ice cream!

I like this analogy for abstraction because the rules are so simple -- I hand over some money, I get an ice cream. The key is that //I don't have to care where the ice cream comes from//:

  * maybe the vendor uses a machine to dispense ice cream into a cone
  * maybe they pull one ready-made from the freezer
  * maybe they run out to the van next door, collect a dispensed/ready-made ice cream and return it to me
  * maybe they make and freeze a batch of fresh ice cream from scratch (OK, so I'd probably notice a delay here, but you get the point...)

If you're looking for a vehicle to explain why abstraction means you don't have to care about implementation, I offer you The Ice Cream Van of Abstraction!

<WRAP center round box>
**Share**: If you found this article useful, please share it! ~~socialite:icon bluesky linkedin reddit facebook email~~
</WRAP>