SQL does not in any way serve as "an API for relational databases". Structured Query Language (SQL) is a domain-specific language (DSL) that is used to manage data in relational database management systems (RDBMS). It excels at set-based operations and is no way an Application Programming Interface (API).
What your examples establish is not that the world is too mess for SQL but that your (and possibly Mr. Nadella's) understanding of and approach to data modeling (not to mention business processes) may be a bit too simplistic.
For example, there is no need to associate a single city and country with a single airport, and international airports are hardly the only examples where trying to do so will probably introduce problems. Relational databases easily support many-to-many relationships where multiple locations can be associated with a single airport, etc.
There are also issues with the assumptions you've made in your quick and dirty data model that will come back to haunt you, but the bottom line is that using a document database for business entity data is simply wrong -- the wrong tool for the job.
Please learn more about SQL and how to use it correctly and well before pronouncing it insufficient. Many, many relational systems disprove your thesis statement all day, every day.
SQL does not in any way serve as "an API for relational databases"...
I know what SQL is, and how it was designed to process data in databases. But some developers and architects have reasons to run some data processing in the application tier, then use SQL as an API to the database service. Wasn't called API in 1992, because two and three tier architecture were not out in the wild, but look at the four "Classes of SQL-statements" in the SQL standard, and you will recognize API.
there is no need to associate a single city and country with a single airport
Yes, but that's exactly the point of the example: normalization forces you to make a Many-to-Many the general case when it is the exception. Yes, of course relational databases support it, but with more complexity, harder query planning, and less declarative integrity constraints (in the absence of assertions define in SQL but implemented in no RDBMS). And getting back to the API: how do you return a Many-to-Many with one SQL statement when the result set is a single two-dimension table?
using a document database for business entity data is simply wrong
If you don't need it and don't want to learn it, then, sure, it's wrong for you, don't use it. But some developers are more successful with it. No reason to be angry, different development approach, skills, architecture decisions, requirements. I like to listen to others point of view. I could have stayed working on SQL databases for life, but I like to listen to developers and share what I learn from them.
Not if you think SQL is an API, regardless of where it's run. APIs are collections of discreet endpoints.
They are interfaces, as the name states, not a language, which SQL is. One cannot, for example, combine or nest API endpoint calls, e.g. GET http://myapp/airports/(GET http://myapp/cities/1), as you can with SQL sub-selects, etc.
... normalization forces you to make a Many-to-Many the general case when it is the exception.
Even more nonsensical. The thing being modeled determines the appropriate approach. Some things are by their nature one-to-many; other things are many-to-many. You've done it correctly if your model accurately reflects reality.
... how do you return a Many-to-Many with one SQL statement when the result set is a single two-dimension table?
You're joking, right? Off the top of my head, something like this:
SELECT
a.*
FROM
Airports a,
Cities c,
AirportCity ac
WHERE
c.Name = 'Amsterdam'
AND c.Id = ac.CityId
If you don't need it [document databases] and don't want to learn it, then, sure, it's wrong for you, don't use it.
No, it's simply the wrong tool for the job. I'm not saying you can't get it to work, but you'll spend more time and money than necessary (and needlessly complicate the tech stack) getting it to work reliably and correctly.
Each correctly-modeled business entity -- a representation of the person, place, and thing (or "noun") our systems are intended to manage -- is by its nature a consistent set of attributes that does not often change. This is ideal for normalized, highly structured, relational tables. Document databases are ideal for semi-structured data that can vary widely from instance to instance.
I use NoSQL databases where they are appropriate. They are not appropriate for entity data.
Please stop sharing what you've learned from listening to developers. It's incorrect on several counts.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Sorry, but this is complete nonsense.
SQL does not in any way serve as "an API for relational databases". Structured Query Language (SQL) is a domain-specific language (DSL) that is used to manage data in relational database management systems (RDBMS). It excels at set-based operations and is no way an Application Programming Interface (API).
What your examples establish is not that the world is too mess for SQL but that your (and possibly Mr. Nadella's) understanding of and approach to data modeling (not to mention business processes) may be a bit too simplistic.
For example, there is no need to associate a single city and country with a single airport, and international airports are hardly the only examples where trying to do so will probably introduce problems. Relational databases easily support many-to-many relationships where multiple locations can be associated with a single airport, etc.
There are also issues with the assumptions you've made in your quick and dirty data model that will come back to haunt you, but the bottom line is that using a document database for business entity data is simply wrong -- the wrong tool for the job.
I could go on and on, but my How Bad Things Happen … in the Data Layer article on Medium covers most of them.
Please learn more about SQL and how to use it correctly and well before pronouncing it insufficient. Many, many relational systems disprove your thesis statement all day, every day.
I know what SQL is, and how it was designed to process data in databases. But some developers and architects have reasons to run some data processing in the application tier, then use SQL as an API to the database service. Wasn't called API in 1992, because two and three tier architecture were not out in the wild, but look at the four "Classes of SQL-statements" in the SQL standard, and you will recognize API.
Yes, but that's exactly the point of the example: normalization forces you to make a Many-to-Many the general case when it is the exception. Yes, of course relational databases support it, but with more complexity, harder query planning, and less declarative integrity constraints (in the absence of assertions define in SQL but implemented in no RDBMS). And getting back to the API: how do you return a Many-to-Many with one SQL statement when the result set is a single two-dimension table?
If you don't need it and don't want to learn it, then, sure, it's wrong for you, don't use it. But some developers are more successful with it. No reason to be angry, different development approach, skills, architecture decisions, requirements. I like to listen to others point of view. I could have stayed working on SQL databases for life, but I like to listen to developers and share what I learn from them.
Not if you think SQL is an API, regardless of where it's run. APIs are collections of discreet endpoints.
They are interfaces, as the name states, not a language, which SQL is. One cannot, for example, combine or nest API endpoint calls, e.g.
GET http://myapp/airports/(GET http://myapp/cities/1), as you can with SQL sub-selects, etc.Even more nonsensical. The thing being modeled determines the appropriate approach. Some things are by their nature one-to-many; other things are many-to-many. You've done it correctly if your model accurately reflects reality.
You're joking, right? Off the top of my head, something like this:
No, it's simply the wrong tool for the job. I'm not saying you can't get it to work, but you'll spend more time and money than necessary (and needlessly complicate the tech stack) getting it to work reliably and correctly.
Each correctly-modeled business entity -- a representation of the person, place, and thing (or "noun") our systems are intended to manage -- is by its nature a consistent set of attributes that does not often change. This is ideal for normalized, highly structured, relational tables. Document databases are ideal for semi-structured data that can vary widely from instance to instance.
I use NoSQL databases where they are appropriate. They are not appropriate for entity data.
Please stop sharing what you've learned from listening to developers. It's incorrect on several counts.