Chris Date, one of the fathers of the relational model for data management, once told me that “All of relational theory is built on predicate calculus.” We stack up factual statements until they create a description of reality. In my book, that’s a story. Humans are all storytellers in one way or another. We adapt storytelling into our daily lives and our daily work. If you are defining a database table and cannot tell the story of the data, you are doing it wrong. A Look at the Nuts and Bolts of Storytelling Good stories follow rules. Pixar famously stacks the elements of a story into a formula they call a story spine: "Once upon a time..." "And every day...""Until one day..." “And because of that…”"And because of that...""Until finally..." "And since that day..." "Once upon a time..." "And every day..." "Until one day..." “And because of that…” "And because of that..." "Until finally..." "And since that day..." One could think of this story spine as the model for good storytelling. Hollywood blockbusters use a similar formula. Following the “rules” of storytelling is why we see Woody as a hero rather than junk, Remy as an artist rather than a health code violation, and Nemo as brave, rather than hopeless. There are plenty of opportunities for creativity within this model’s rules. Storytellers who internalize the rules of good storytelling are sought after to create new stories and new movies. Some directors, writers, and producers may diverge from these best practices of storytelling to tell stories that do not fit within the standard storytelling model, but films that lack a clear story will flop at the box office every time, even if they’re beautifully shot. How We Engineer Stories with Data In the world of technology, like in Hollywood, our stories are not just written down; they are acted upon. We instruct electrons to carve runes into structures we define. Other technologists or knowledge workers may refer back to what we’ve made for years to come. The relational model for data management that Chris Date and Ted Codd defined in the 1960s and 70s solved many problems that had existed prior to its creation. SQL Server, Oracle, Snowflake, Redshift, MySQL, Clickhouse, Cockroach DB, DuckDB, and on and on would not exist without the work of these two gentlemen. Chris Date Ted Codd Here’s an example table referenced from their book, An Introduction to Database Systems: EMP# ENAME DEPT# SALARY E1LopezD140KE2ChengD142KE3FinziD230KE4SaitoD235K EMP# ENAME DEPT# SALARY E1LopezD140KE2ChengD142KE3FinziD230KE4SaitoD235K EMP# ENAME DEPT# SALARY E1LopezD140KE2ChengD142KE3FinziD230KE4SaitoD235K EMP# ENAME DEPT# SALARY EMP# EMP# ENAME ENAME DEPT# DEPT# SALARY SALARY E1LopezD140K E1 Lopez D1 40K E2ChengD142K E2 Cheng D1 42K E3FinziD230K E3 Finzi D2 30K E4SaitoD235K E4 Saito D2 35K In the abstract, this predicate is defined as: “Employee EMP# is named ENAME, works in department DEPT#, and earns a salary of SALARY.” In the concrete, we can interpret this to be: “Employee E1 is named Lopez, works in department D1, and earns a salary of 40K.” It’s easy to tell the story of the data this table represents, which is how you know you’re doing it right. Why AI Can’t Solve Your Database Performance Issues I have been brought in time and again to situations where database performance was thought to be poor, only to discover that the data structures the application developers had created completely disregarded decades of well-documented best-practice rules that ensure effective storytelling. This is not a problem that AI can solve. If application developers or even business users write the prompts that our text-processing and text-generation tools use, those tools will generate text that must then be incorporated into actual working code and stable data structures. Unless the people implementing these rules understand them and their rationale, the only thing that will happen is that poorly performing data structures will be created faster. Tools and techniques will only take you so far in telling the story of your enterprise. Whether your role is the architect, developer, engineer, user, or any other title that may arise in the future, you are ultimately responsible for what is persisted, stored, represented, and used to solve future problems. Returning to these best practices, which have been around for decades, will make you a better, more creative builder. This Is How You Make Your Mark Yes, you are one small part of an enterprise. Nevertheless, you want to leave your own mark on the world, right? Why are you there, and what good will you do? Whitman asked a similar question in his poem “O me, O Life!” "What good amid these, O me, O life?" "What good amid these, O me, O life?" The answer for all of us is: "That you are here—that life exists and identity, "That you are here—that life exists and identity, That the powerful play goes on, and you may contribute a verse." That the powerful play goes on, and you may contribute a verse." What story will you decide to tell? If you’re a Snowflake database administrator or data engineer, DataOps.live can help. Get started today — you get 500 minutes free every month! If you’re a Snowflake database administrator database administrator or data engineer data engineer , DataOps.live can help. Get started today — you get 500 minutes free every month! you get 500 minutes free every month!
