I will second the commenter who said that relational databases are lovely but SQL is clunky. I'll take it a step further and say that SQL is a design flaw impo

I will second the commenter who said that relational databases are lovely but SQL is clunky. I'll take it a step further and say that SQL is a design flaw imposed on us by large database vendors that we have been paying the price for for the past 50 years. There is a principle, included in SOLID, called "interface segregation" and it is the idea that having many, smaller, special-purposes interfaces is preferable to having fewer, larger more general-purpose interfaces. To understand the principle complete, just think about the differences between a consumer toaster oven and the cockpit of a Boeing 747 jet airplane. One can be operated by a five year-old (with supervision) while the other requires years of training and specialized domain knowledge to operate. In software, you can't get any more "general purpose" than a programming language. Consider the complexity that SQL has brought us over the past half a century: SQL injection vulnerabilities, object relational mappers, complex and computationally-expensive queries that are difficult to understand let alone optimize, business logic hidden inside of stored procedures and on and on we go. Basically all of the problems and challenges that are inherent in any kind of human-crafted code can be found inside of SQL and it is just an interface in front of a data storage / persistence engine. That doesn't mean that SQL is the most challenging language to learn and master. It just means that we have taken something special purpose (data persistence) and stuck a very general purpose interface in front of it with all of the complexity that doing so invites.