1 Comment

> in SQL you’d have a rule that says “select must be followed by one or more column names” in OpenAPI you’d say “the value of $ref must be a path to a schema”.

>

> The fundamental difference here is that I’ve not had to define what “value” means because the OpenAPI DSL exists within a much more generalised and well-defined language which defines keys, values, lists and scalar data types already.

I'm not understanding your point here. A database schema is equivalent to an OpennAPI schema.

> The fundamental difference here is that I’ve not had to define what “value” means because the OpenAPI DSL exists within a much more generalised and well-defined language which defines keys, values, lists and scalar data types already.

Isn't that true of a database schema too?

There's a fundamental difference between an Open API schema and a database schema. Open API schemas are describing an HTTP API that is written in a different language. The Open API schema is either generated by annotating or parsing the host language, or it's written more manually/ad hoc. There is no guarantee the schema actually matches the API, or that that the Open API schema can map to all the functionality available in the host app. Whereas, a database schema exactly matches the database's API.

As for the comments on SQL, really SQL is no different from sending a shader to a GPU, or script or bytecode or intermediary language to an interpreter or VM, or sending instructions to a CPU, or an HTTP request to an HTTP server, or any other example of sending data from between disparate processes. So yeah sure the syntax could be improved and optimised, but optimised for what?\ Sure, there are plenty of ways the data could be sent, but its very common for languages to have several stages of transformation from something a human can read and write and understand, to something that can program a computer to do something. SQL is no different. I suppose what you are really wanting is an intermediary language, that host languages can generate rather than SQL.

The other complicating factor is that RDBMs generally work differently from most other software. They are always live. Changes aren't deployed; the system doesn't come down or get replaced when the database schema changes. The schema is migrated in the live system. Not many systems have this capability. It requires a different paradigm of programming. Rather than coding classes or structs, you code schema changes. So host applications are really at a disadvantage when they need static code compilation at compile time to generate an ORM to query the database. It opens up a more generic question or how do you keep the APIs between two disparate systems in sync with each other? E.g. the same problem exists for OpenAPI schemas. The schema changes, the clients need updating.

Expand full comment