4 ms·

0. Finally, an API that actually attempts to fit modern programming paradigms! I'm not sure the unstructured nature of many NoSQL databases was even the sellin

0. Finally, an API that actually attempts to fit modern programming paradigms! I'm not sure the unstructured nature of many NoSQL databases was even the selling feature so much as the NoSQL part. People were growing tired of dealing with lacklustre ORMs and poor integration with their programming tools and were desperate, even in light of the shortcomings, to try something new. It is funny that we have a thousand and one different general purpose programming languages that try to solve the problems with general purpose computing, but SQL dialects (with slight variation here and there), have very little competition, despite all the problems with the SQL language. A NoSQL relational database could have potentially hit the sweet spot, but Mongo and similar databases came first and caused enough trouble, as you have described, that I feel like they've killed the momentum in looking for better solutions to access database data (relational ones included). Nowadays many of those people are just happy to have a relational database again, even that means accepting SQL.

jdmichal 9y ago
> It is funny that we have a thousand and one different general purpose programming languages that try to solve the problems with general purpose computing, but SQL dialects (with slight variation here and there), have very little competition, despite all the problems with the SQL language. This is kinda like complaining that there's only one implementation of lambda calculus. Yes, SQL is not directly a relational algebra, but it's pretty close. (Also, tables are not relations and SQL deals with that.)
- randomdata 9y ago
  > This is kinda like complaining that there's only one implementation of lambda calculus. Yes, SQL is not directly a relational algebra, but it's pretty close. And yet someone proficient in SQL will not necessarily be able to read a traditionally-written lambda calculus expression as the languages differ significantly (and not just because of tables), so I think this proves my point that there are different, and hopefully better, ways to express the interaction with the database. There is no reason why the protocol has to be exactly as SQL is. There are theoretically an infinite number of ways to communicate the same intent to a RDBMS. For instance, SQL does not do composability well. There is no fundamental reason why you should not be able to write query fragments, simplifying the way many queries are constructed and avoiding the huge mess that monolithic, hard to debug, queries often become. It is simply that SQL does not allow for it. A better API could improve on this significantly, without losing any features a relational database provides. You don't have to throw all database theory out the window just to change the API away from one that was designed 40 years ago.
  - jdmichal 9y ago
    > And yet someone proficient in SQL will not necessarily be able to read a traditionally-written lambda calculus expression as the languages differ significantly (and not just because of tables), so I think this proves my point that there are different, and hopefully better, ways to express the interaction with the database. There is no reason why the protocol has to be exactly as SQL is. There are theoretically an infinite number of ways to communicate the same intent to a RDBMS. First, lambda calculus isn't a language -- at least, not in the typical sense. It's a mathematical logic construct. It's more akin to geometry than to a programming language. Same applies to relational algebra. And of course lambda calculus and relational algebra differ significantly... Their domains are completely disjoint. I was not comparing them in this way. I'll restate my premise: If we consider SQL a mapping of relational algebra operators to SQL operators [0], then any other language which also maps to relational algebra will not be significantly different. Thus, complaining about SQL being a singularity is kinda like complaining that relational algebra, lambda calculus, or any other mathematical constructs are singularities. > For instance, SQL does not do composability well. There is no fundamental reason why you should not be able to write query fragments, simplifying the way many queries are constructed and avoiding the huge mess that monolithic, hard to debug, queries often become. It is simply that SQL does not allow for it. A better API could improve on this significantly, without losing any features a relational database provides. You can compose SQL with views. Non-materialized views act as pure SQL composition. Materialized views allow precalculation of subexpressions. Most of the big databases also support common table expressions, which allow for decomposition within a single query. https://en.wikipedia.org/wiki/Hierarchical_and_recursive_queries_in_SQL#Common_table_expression https://en.wikipedia.org/wiki/Hierarchical_and_recursive_que... > You don't have to throw all database theory out the window just to change the API away from one that was designed 40 years ago. Of course not. The problem is that any new SQL would just be a new mapping for the same underlying relational algebra. "Welcome to the new SQL, same as the old SQL." [0] It's not, because tables aren't relations. However, the operators are similar enough that parallels are easily drawn.
    - randomdata 9y ago
      > First, lambda calculus isn't a language -- at least, not in the typical sense. There are common ways to express lambda calculus expressions in order for people to communicate those expressions with each other, which is very much a language. After all, we are talking about the language of SQL here, not the mathematical concepts that lie beneath the language. Don't confuse what SQL is able to achieve with the way SQL is written. We are discussing only the latter. > The problem is that any new SQL would just be a new mapping for the same underlying relational algebra. And general purpose programming languages map to the same underlying turing machine. That hasn't stopped us from coming up with variations in language to improve the developer experience, even if they are all quite similar at the end of the day. Let's face it, if you can program in one general purpose programming language, you can program in them all. There are no real differences between them. The only thing to learn when switching languages is the grammar and idioms of the language. The underlying mathematical theory never changes. You could just as easily say "Welcome to the new C, same as the old C." And yet, the new C has proven to be quite valuable when it comes to developer productivity and happiness. There is very much room for the same in SQL land, if someone was ever motivated enough to look for it. I maintain that NoSQL becoming synonymous with unstructured key-value/document data stores has killed what motivation there may have been though.

jdmichal 9y ago

> It is funny that we have a thousand and one different general purpose programming languages that try to solve the problems with general purpose computing, but SQL dialects (with slight variation here and there), have very little competition, despite all the problems with the SQL language. This is kinda like complaining that there's only one implementation of lambda calculus. Yes, SQL is not directly a relational algebra, but it's pretty close. (Also, tables are not relations and SQL deals with that.)

randomdata 9y ago
> This is kinda like complaining that there's only one implementation of lambda calculus. Yes, SQL is not directly a relational algebra, but it's pretty close. And yet someone proficient in SQL will not necessarily be able to read a traditionally-written lambda calculus expression as the languages differ significantly (and not just because of tables), so I think this proves my point that there are different, and hopefully better, ways to express the interaction with the database. There is no reason why the protocol has to be exactly as SQL is. There are theoretically an infinite number of ways to communicate the same intent to a RDBMS. For instance, SQL does not do composability well. There is no fundamental reason why you should not be able to write query fragments, simplifying the way many queries are constructed and avoiding the huge mess that monolithic, hard to debug, queries often become. It is simply that SQL does not allow for it. A better API could improve on this significantly, without losing any features a relational database provides. You don't have to throw all database theory out the window just to change the API away from one that was designed 40 years ago.
- jdmichal 9y ago
  > And yet someone proficient in SQL will not necessarily be able to read a traditionally-written lambda calculus expression as the languages differ significantly (and not just because of tables), so I think this proves my point that there are different, and hopefully better, ways to express the interaction with the database. There is no reason why the protocol has to be exactly as SQL is. There are theoretically an infinite number of ways to communicate the same intent to a RDBMS. First, lambda calculus isn't a language -- at least, not in the typical sense. It's a mathematical logic construct. It's more akin to geometry than to a programming language. Same applies to relational algebra. And of course lambda calculus and relational algebra differ significantly... Their domains are completely disjoint. I was not comparing them in this way. I'll restate my premise: If we consider SQL a mapping of relational algebra operators to SQL operators [0], then any other language which also maps to relational algebra will not be significantly different. Thus, complaining about SQL being a singularity is kinda like complaining that relational algebra, lambda calculus, or any other mathematical constructs are singularities. > For instance, SQL does not do composability well. There is no fundamental reason why you should not be able to write query fragments, simplifying the way many queries are constructed and avoiding the huge mess that monolithic, hard to debug, queries often become. It is simply that SQL does not allow for it. A better API could improve on this significantly, without losing any features a relational database provides. You can compose SQL with views. Non-materialized views act as pure SQL composition. Materialized views allow precalculation of subexpressions. Most of the big databases also support common table expressions, which allow for decomposition within a single query. https://en.wikipedia.org/wiki/Hierarchical_and_recursive_queries_in_SQL#Common_table_expression https://en.wikipedia.org/wiki/Hierarchical_and_recursive_que... > You don't have to throw all database theory out the window just to change the API away from one that was designed 40 years ago. Of course not. The problem is that any new SQL would just be a new mapping for the same underlying relational algebra. "Welcome to the new SQL, same as the old SQL." [0] It's not, because tables aren't relations. However, the operators are similar enough that parallels are easily drawn.
  - randomdata 9y ago
    > First, lambda calculus isn't a language -- at least, not in the typical sense. There are common ways to express lambda calculus expressions in order for people to communicate those expressions with each other, which is very much a language. After all, we are talking about the language of SQL here, not the mathematical concepts that lie beneath the language. Don't confuse what SQL is able to achieve with the way SQL is written. We are discussing only the latter. > The problem is that any new SQL would just be a new mapping for the same underlying relational algebra. And general purpose programming languages map to the same underlying turing machine. That hasn't stopped us from coming up with variations in language to improve the developer experience, even if they are all quite similar at the end of the day. Let's face it, if you can program in one general purpose programming language, you can program in them all. There are no real differences between them. The only thing to learn when switching languages is the grammar and idioms of the language. The underlying mathematical theory never changes. You could just as easily say "Welcome to the new C, same as the old C." And yet, the new C has proven to be quite valuable when it comes to developer productivity and happiness. There is very much room for the same in SQL land, if someone was ever motivated enough to look for it. I maintain that NoSQL becoming synonymous with unstructured key-value/document data stores has killed what motivation there may have been though.