TL;DR: Always use a SQL-script too demonstrate what you to do. And make it Repeatable, and preferable Self-explaining. That way, anyone can quickly see for themselves what you want to say.
Intro: Always the Database...
But piet, you want to offer a Database Solution for Everything... !
My reply: Off Course I do. You work with Data.. then the Database can + should Help you. And the database (with SQL) is probably the simplest solution to what you want to achieve...
image: Always have a (demo-)script to run....
Background: How I learned to use SQL(-scripts) to show things.
I have to pay tribute to Tom Kyte (from asktom), Tim Hall (from ora-base), and more recently Connor McDonald (link) for showing me many useful things for my work as an Oracle DBA- and database-plumber and an overall Database-SME (Subject-Matter-Expert...).
The main trick in showing things to colleagues is to Explain what you want them to know and then Show it, Demo it. Preferably with an SQL script. A script that can be copied and re-used as a basis for the program/system/solution/script that you want them to build.
NB: This topic seems a suitable item as my entry for the #JoelKallmanday this year.. Details in the post by Tim Hall (link).
Explain to Colleagues or audience what you want... (and Show it)
In most cases, when I want to show something new, or suggest a database-solution to others: I create a demo-script. You can try endlessly to "explain" a feature or a way to process data in the database (often preferable to any other tool). But to really convince people, to "Win Them Over" you have to demonstrate it.
Example1: the use of ENUM for LoVs (link). I first played with the SQL-statements, wrote a script. Then I started composing the blog and the script together so they would match and provide a readable and runnable combinations.
Example2: Demo "SQL-Assertions" (link) and show some of what what happens underneath (link). Again I started toying with the statements.
Example3: The new feature of SQL-History in Oracle 26ai (link). I wanted to build this into some of the python-programs we used to find "the heavies" in there. But I first I had to demonstrate "why" and "how". And again, starting from pure-SQL was the best way to show what the feature can do. (incidentally: can this SQL-history be back-ported to v19c ?? just asking gently...)
All of those blog were written around one or two files that the reader can download, and run for themselves to replay the demo and see what is happening. And maybe to "build on" for further usage of the feature described.
No Demo = no argument.
Without providing examples, I now tend to come across blogs, vlogs, and other content where someone Loads Praise on a feture (Vectors, LLM, zero-failover, or more weird-Sci-Fi stuff) but does not provide a simple, re-rerunnable, Demo for me to Use. I can understand that some topics require more study, more installing, more work, or even "hardware" before you can use them properly. But without a demo-to-copy, I find it rather damages the credibility of the message.
A Good Example of Doing it Right was Francisco at POUG in 2023, who told us his message and then fearlessly went "This is POUG - Let's Demo!". He showed us that it Really Worked (it was a live-patch with Zero Downtime).
I also recall a very old case (early 2002) where the data-model and the data-usage lend itself to using IOTs (Index Organized Tables, link?). I went out of my way to argue how data-proximity would benefit this system. Storing all descendants of a parent records, would facilitate the retrieval of the sets of "childeren" from a given parent. But in the end, a demo with a sizeable data-set was more convincing than all my argumenting, my talking and my powerpointing. It was at that point that I realised that Tom Kyte was Right: Always have a Demo(-script).
That demo, btw, was later simplified into a a few blogposts and into a presentation that was given 10+ times at various conferences... and still works. Good Memories (link to scripts below - demo_iot/2.sql)
Requirement for demo-scripts: Run without Hassle.
(This is the advice that I probably ignored the most with my own demos)
Whenever you create a scripts for demo-use, Keep It Simple. It should be runnable at just about any promt (provided it is Oracle SQL): SQL*Plus, SQLcl. But also from SQLDeveloper (classic or VSCode), and even from exotics like "the frog" (IYKNY) or DBeaver.
It should also perferably do come explaining by itself. I often include comments and "prompt-statements" to do this. Note that I tend to overdo the echos and prompts, and too many echos and prompts can make the script a bit weird.
Furthermore, try to Minimize any "setup" that is needed. I broke that rule when I requested ppl to install the oracle-supplied demo of scott/tiger/emp/dept for some of my own demos. Normally, I try to prevent that.
Also: Make the demo easily "re-runnable". The outcome of your demo should be identical at every run. The Devops-folks call this "Idempotency" (google it if needed).
And finally : Make it do its own cleanup. Make it drop any created objects and rollback any modified data. (I often break this rule myself as well, but ...), This is mostly a matter of politeness and cleanliness...
It takes some Effort, but it pays off
I realize that building a good, clear, smooth-running, and self-explaning script it not always simple: It Takes Effort. I know that from dire experience: I used to send script to colleagues with comment "this will do it". And in many cases, they failed to grasp the meaning. Or worse: they mis-interpreted and switch the "bad part" with the "good part" and built exactly the wrong code.
By spending some time to demo stuff, you will a) Learn more and b) Get Re-Usable snippets. In several cases I could go back to years-old scripts and re-demo it, re-use it to show a possible solution in minutes. Some cstmrs are properly impressed when you come up with a solution that quickly (downside is they expect you to solve Everything before the day is over).
Another Example: Oracle-Base dot com...
Good SQL-runnable Examples, This is exactly why the site Oracle-base.com from Tim Hall is so popular: Every page has the same pattern : It explains what he wants to say, and then contains Ready-to-Run code-examples. And of course you can copy the statements from the examples for your own use.
Final Example: mk_rerun.sql...
(did I ever blog about this one ? , Actually, Yes..)
https://simpleoracledba.blogspot.com/2023/07/find-and-use-bind-variables-from-sql.html
This script will take an SQL_ID, and generate a (nearly) re-runnable script for it. It pickes the statement from v$, it tries to find the latest bind-vars from v$, and it puts it all together in a file you you can edit to make it runnable. It has a lot of caveats, notably around variable-types (dates were problematic to define as as bind-vars...).
The Script... (link)
This post is partly created bcse I recently used this script again at a cstmr to show how certain values of input-values (assingned to the bind-vars) could send a query off into the sunset.
Concluding: Scripted SQL-demos are Worth it.
By spending some time to demo stuff, you will a) Learn more and b) Get Re-Usable snippets. In several cases I could go back to years-old scripts and re-demo it, re-use it to show a possible solution in minutes. Some cstmrs are properly impressed when you come up with a solution that quickly (downside is they expect you to solve Everything before the day is over).
But I think the idea is clear: A good database-story should have some good, runnable, Demo-Scripts. I did many done presentations with good (and some less-good) SQL-scripts to go with them. I think we should make that point to new presenters as well.
And about that Database Solution...
To come back to "Always a Database Solution" .. Sure, there is more than just SQL. And yes, I have looked beyond the database.
But because most Information is Data, in many cases a Database Solution should be your first call. And if you Demo your ideas properly, you may actually convince some colleagues.
-- -- -- -- -- End of this Blog, for now -- -- -- --
Links to demo-script mentioned:
demo_iot.sql : first part of the demo, going back to 2009 or so, still valid.
demo_iot2.sql : 2nd part of the demo.
mk_rerun.sql : if you ever need to re-run an SQL from command prompt.
-- -- -- -- End of this blog-entry, For Real -- -- -- --
No comments:
Post a Comment