Why Is SQL a Poor Interface for Applications?

TL;DR

SQL is a poor application interface because programs often construct syntax-sensitive query strings instead of calling functions with clear inputs and outputs. Robert Martin argues that SQL suits console-based querying and report printing, while the counterargument is that its declarative syntax gives database engines room to validate requests, plan execution, and manage storage. Read on to see why APIs and ORMs improve ergonomics without necessarily replacing SQL.

Transcript

SQL was never intended to be used by computer programs. It was a console language for printing reports. Embedding it into programs was one of the gravest errors of our industry. Normally, I don't talk much about Uncle Bob's takes on this channel. We are not super aligned overall, but I have a few reasons I want to cover this today. One is that I do... Read More

Key Insights

• SQL is a declarative interface that lets a database determine how to retrieve requested data. A query engine can parse a compact statement, validate its references, select an execution strategy, generate lower-level instructions, and interact with storage without requiring application developers to coordinate those operations manually.
• The central criticism of SQL is that programs must often submit strings instead of calling typed functions. Robert Martin considers that an unsuitable programming interface because developers would prefer explicit operations with simple inputs and outputs, such as retrieving a user by an identifier.
• SQL was characterized by Martin as a language created for people working at consoles or teletypes and printing reports. His argument is not that querying data is unnecessary, but that embedding this console-oriented syntax directly inside application code was a major design mistake.
• ORMs are not accepted as a complete answer to SQL's application-interface problems. They can place an object-oriented abstraction over database access, but the underlying system still issues SQL, so the wrapper changes how developers express requests without removing the query language or database complexity.
• A database API does not automatically eliminate SQL because its implementation still needs a query protocol. If an API merely receives application calls and converts them into SQL, it wraps the same mechanism, while a genuine replacement would require inventing and supporting another way to express queries.
• SQLite processes a simple query through multiple stages, including tokenization, parsing, name and type analysis, query planning, code generation, and virtual-machine execution. Its planner may select an index for an identifier lookup when one exists or choose a full table scan when it does not.
• Direct access to database internals would burden application developers with substantial implementation complexity. Even a simple request for selected user fields can involve parsing functions, planning logic, generated bytecode, B-tree storage operations, and a large internal selection function rather than one straightforward application-level call.
• The practical position is that SQL has genuine weaknesses but remains preferable to available alternatives. Better schema primitives, type safety, and application integration would help, yet abandoning SQL without an equally capable abstraction could force developers to accept systems that are more complicated or less effective overall.

Questions & Answers

Q: Why is SQL considered a poor interface for applications?

Applications commonly construct SQL strings and pass them into an API instead of calling functions with explicit inputs and outputs. Robert Martin argues that SQL is suitable for querying a database from a console but poorly matched to application code.

Q: What was SQL originally intended for, according to Robert Martin?

Martin characterizes SQL as a console language for querying databases and printing reports. His objection is specifically to embedding that console-oriented syntax into computer programs as their database interface.

Q: What interface does Robert Martin want databases to provide?

He wants databases to expose an API whose functions have simple inputs and outputs. Instead of constructing a SELECT-WHERE string, an application could call an operation that directly represents the requested data access.

Q: Can a database API replace SQL?

An API does not eliminate SQL if its functions merely issue SQL underneath. A genuine replacement would require a new query protocol; otherwise, the API only wraps the same mechanism, potentially through HTTP.

Q: Why are ORMs not a complete solution to SQL's interface problems?

ORMs can hide direct SQL construction behind an object-oriented abstraction, but they still must translate application operations into database requests. Martin also rejects ORMs as the desired alternative, so they do not resolve his underlying demand for a function-based database interface.

Q: What happens when SQLite processes a SQL query?

SQLite tokenizes and parses the statement, analyzes referenced names and types, and creates an execution plan. It then generates virtual-machine bytecode and executes it against the storage engine.

Q: Why is SQL's declarative approach useful?

SQL lets an application describe the data it wants without manually coordinating storage-level operations. The database can validate the request, choose an execution strategy, generate lower-level instructions, and retrieve the data.

Q: What is the balanced case for keeping SQL despite its flaws?

SQL has genuine application-integration weaknesses, including string-based requests, limited type safety, and inadequate schema-management primitives. However, replacing it means providing another way to express queries while preserving the database's planning, execution, and storage capabilities, so the available alternatives may add complexity rather than remove it.

Summary & Key Takeaways

• Robert Martin argues that SQL was designed as a console language for querying databases and printing reports, not as a programming interface. He objects to applications passing query strings into an API and would prefer callable functions with simple inputs and outputs, although he also rejects ORMs as an adequate solution.

• The counterargument is that SQL provides a declarative interface over extensive database machinery. In SQLite, a query is tokenized, parsed, analyzed, planned, translated into virtual-machine bytecode, and executed against the storage engine. A short statement therefore activates far more internal work than its compact surface syntax suggests.

• The balanced conclusion is that Martin identifies real integration problems without establishing a practical replacement. SQL lacks ideal schema-management primitives, type safety, and application integration, yet direct calls into database internals would expose overwhelming complexity. An API or ORM may improve ergonomics, but it still relies on SQL or another query protocol underneath.