Please log in to watch this conference skillscast.
Many real-world lots-of-business-value-providing systems use a relational database. (Even more of them should!) Often, that database is used as a dumb data store – nothing more, logically, than an ACID-compliant coordinator of multiple flat files (tables). We send it basic queries – sometimes even joining multiple tables in one query! – inserts, updates and deletes. But nothing that might strain its little brain. Often, this is a mistake: a modern relational database is the most sophisticated data-munging tool in our toolkit!
We should consider doing more work in the database itself. But that's not easy to code well. How can we make our more complex SQL code easier to reason about, more reliable, and more testable? How can we make the overall system simpler?
These are questions that in not-the-database contexts, we solve with functional programming techniques. Without expecting SQL to out-lambda Haskell, are there techniques that we can borrow from functional programming and apply to improving our SQL?
YOU MAY ALSO LIKE:
- Functional CRUD: Using ‘Bureaucracy’ To Tame a Full-stack Clojure / ClojureScript App (SkillsCast recorded in April 2016)
- co-log: Composable Contravariant Comonadic Logging Component (SkillsCast recorded in May 2019)
- Functional Programming in Spring with Arrow, Lenses and Effects (SkillsCast recorded in May 2019)
Functional Programming in ... SQL?
Sam Roberton
Engineering ManagerRokt