4 ms·

well, obviously "worse is better". historically, SQL has been "Good enough" and was sponsored by IBM/Oracle that nobody has bothered to try and implement the re

well, obviously "worse is better". historically, SQL has been "Good enough" and was sponsored by IBM/Oracle that nobody has bothered to try and implement the relational model correctly, except for perhaps postgres (which used to have its own query language before bolting SQL onto its core engine) what I hope people get out of my comments is not about selecting the right system for today- A better thing does not necessarily exist yet-- But at least understand the relational model well enough to see what its utility is. Functional programming and Logic programming are coming back in fashion, and maybe someone here will build the better thing. I don't think "nosql" databases or graph databases are necessarily the better thing. (but they might be for certain usecases). Though I think relational db systems could learn something about developer ergonomics from them. Interfacing with a DB using a fortran inspired query language is archaic. Constructing the queries using string concatenation has been a security nightmare. You could build something waaayyy better off of prolog or mercury, full programming languages with the inductive logic engine at the core of their paradigm, with a database system integrated in, and expose a graphql api for your isomorphic react web app cos that's how we do in 2018. Even microsoft's linq is a massive improvement over using SQL. Language integration, strong typing. These are things we like, right?

paulddraper 8y ago
> well, obviously "worse is better". > A better thing does not necessarily exist yet Ah, of course. > Interfacing with a DB using a fortran inspired query language is archaic. Constructing the queries using string concatenation has been a security nightmare. Perhaps, but this this often for very ubiquitous technologies. See almost every HTML authoring tool. You can write full application servers in Oracle PL/SQL now. [1] And with PostgreSQL's row-level security, you can easily have a GraphQL server with PostGraphile [2]. But those aren't popular solutions. > ou could build something waaayyy better off of prolog or mercury, full programming languages with the inductive logic engine at the core of their paradigm That doesn't really change the equation. You still either have to (1) choose your DBMS's query language to write your application server (like today) or (2) use one language to construct queries in another (like today). I won't argue that a Prolog DBMS wouldn't be nice. I will argue that in terms of the hard parts of a DBMS, it's not going to fundamentally change things. [1] https://docs.oracle.com/cd/B28359_01/appdev.111/b28424/adfns_psp.htm#g2475353 https://docs.oracle.com/cd/B28359_01/appdev.111/b28424/adfns... [2] https://www.graphile.org/postgraphile/ https://www.graphile.org/postgraphile/
- ZenPsycho 8y ago
  first off, thanks for the links. Secondly, > That doesn't really change the equation. You still either have to (1) choose your DBMS's query language to write your application server (like today) or (2) use one language to construct queries in another (like today). I don't know if you're misunderstanding me, or I'm misunderstanding you. prolog is a query language. The logical programming paradigm is that a program is a "list of facts" and you run the program by "querying" the state of the world. The only piece missing is making the fact storage engine scalable/robust/production ready. Or.. alternatively, there's the Eve[1] project which starts off with prolog to make a hypercard like environment with a built in data storage layer. Its aim is less production ready apps and more developer ergonomics. [1]: ( http://witheve.com http://witheve.com )
  - paulddraper 8y ago
    I don't think I misunderstood. You yearn for the day when a DBMS uses Prolog for its query language. Users of that DBMS have the choice to either (1) query seamlessly because they use prolog for the entire application (2) query by "gluing" Prolog to their application language.
- mamcx 8y ago
  The main problem that I see is that relational model / sql is ALWAYS coupled with RDBMS, even with the proponents of the relational model! The thing is, sql is much less capable then even forth. You can't do: query = where a = ?1 columns = [name, id ] console.write(columns ?rename name as a |> query) not even console.write not even Window.open neither store table in a field (not serializate it, store) create your btree, make open gl game, make a osx app, create a rdbms and so on. (yes, i'm aware some rdbms could, hacking around, kind of do it witth pain) In short, the relational model is not see as something that can be made for a full language WITHOUT RDBMS. That is what I wish to change: http://tablam.org/ http://tablam.org/ because I work before as foxpro developer and see how easy and logical was to work with tables without sql.
  - paulddraper 8y ago
gnufx 8y ago
> Interfacing with a DB using a fortran inspired query language is archaic. Possibly amusing aside: Logica's RAPPORT, one of the earliest RDBs, was written in Fortran and was queried (or could be) via pre-processed Fortran. I don't know whether that was more faithful to the model than SQL. Jaffer's Scheme RDB (https://people.csail.mit.edu/jaffer/slib/Relational-Database.html https://people.csail.mit.edu/jaffer/slib/Relational-Database...) aimed to implement the model, possibly uniquely so at the time, he thought.
- tabtab 8y ago
  Actually, SQL seems more COBOL-inspired than FORTRAN-inspired to me. As far as a "generic" query language not tied to relational databases, that's a rather tall order. Logic-based query languages are difficult to troubleshoot when you don't get the results you expected. It's kind of like a formalized version of Google: you get results, but you don't know if they are the best results, you don't know what you are missing, and you often don't know why you got what you did. You have to have some kind of discipline and structure to the data in order to understand and troubleshoot results (at least for mortals and non-Sheldons). Some say relational is "too stiff" for some uses, but there is the Dynamic Relational proposal that gives it flexibility without abandoning relational and SQL. (Some argue it's not technically relational, which I don't agree with, but that issue doesn't change the similarity to existing RDBMS & SQL conventions.) As far as relational-based alternatives to SQL, consider these discussions: http://wiki.c2.com/?HowOtherQueryLanguagesAddressSqlFlaws http://wiki.c2.com/?HowOtherQueryLanguagesAddressSqlFlaws http://wiki.c2.com/?QueryLanguageComparison http://wiki.c2.com/?QueryLanguageComparison http://wiki.c2.com/?ExperimentalQueryLanguageComparison http://wiki.c2.com/?ExperimentalQueryLanguageComparison

paulddraper 8y ago

> well, obviously "worse is better". > A better thing does not necessarily exist yet Ah, of course. > Interfacing with a DB using a fortran inspired query language is archaic. Constructing the queries using string concatenation has been a security nightmare. Perhaps, but this this often for very ubiquitous technologies. See almost every HTML authoring tool. You can write full application servers in Oracle PL/SQL now. [1] And with PostgreSQL's row-level security, you can easily have a GraphQL server with PostGraphile [2]. But those aren't popular solutions. > ou could build something waaayyy better off of prolog or mercury, full programming languages with the inductive logic engine at the core of their paradigm That doesn't really change the equation. You still either have to (1) choose your DBMS's query language to write your application server (like today) or (2) use one language to construct queries in another (like today). I won't argue that a Prolog DBMS wouldn't be nice. I will argue that in terms of the hard parts of a DBMS, it's not going to fundamentally change things. [1] https://docs.oracle.com/cd/B28359_01/appdev.111/b28424/adfns_psp.htm#g2475353 https://docs.oracle.com/cd/B28359_01/appdev.111/b28424/adfns... [2] https://www.graphile.org/postgraphile/ https://www.graphile.org/postgraphile/

ZenPsycho 8y ago
first off, thanks for the links. Secondly, > That doesn't really change the equation. You still either have to (1) choose your DBMS's query language to write your application server (like today) or (2) use one language to construct queries in another (like today). I don't know if you're misunderstanding me, or I'm misunderstanding you. prolog is a query language. The logical programming paradigm is that a program is a "list of facts" and you run the program by "querying" the state of the world. The only piece missing is making the fact storage engine scalable/robust/production ready. Or.. alternatively, there's the Eve[1] project which starts off with prolog to make a hypercard like environment with a built in data storage layer. Its aim is less production ready apps and more developer ergonomics. [1]: ( http://witheve.com http://witheve.com )
- paulddraper 8y ago
  I don't think I misunderstood. You yearn for the day when a DBMS uses Prolog for its query language. Users of that DBMS have the choice to either (1) query seamlessly because they use prolog for the entire application (2) query by "gluing" Prolog to their application language.
mamcx 8y ago
The main problem that I see is that relational model / sql is ALWAYS coupled with RDBMS, even with the proponents of the relational model! The thing is, sql is much less capable then even forth. You can't do: query = where a = ?1 columns = [name, id ] console.write(columns ?rename name as a |> query) not even console.write not even Window.open neither store table in a field (not serializate it, store) create your btree, make open gl game, make a osx app, create a rdbms and so on. (yes, i'm aware some rdbms could, hacking around, kind of do it witth pain) In short, the relational model is not see as something that can be made for a full language WITHOUT RDBMS. That is what I wish to change: http://tablam.org/ http://tablam.org/ because I work before as foxpro developer and see how easy and logical was to work with tables without sql.
- paulddraper 8y ago

gnufx 8y ago

> Interfacing with a DB using a fortran inspired query language is archaic. Possibly amusing aside: Logica's RAPPORT, one of the earliest RDBs, was written in Fortran and was queried (or could be) via pre-processed Fortran. I don't know whether that was more faithful to the model than SQL. Jaffer's Scheme RDB (https://people.csail.mit.edu/jaffer/slib/Relational-Database.html https://people.csail.mit.edu/jaffer/slib/Relational-Database...) aimed to implement the model, possibly uniquely so at the time, he thought.

tabtab 8y ago
Actually, SQL seems more COBOL-inspired than FORTRAN-inspired to me. As far as a "generic" query language not tied to relational databases, that's a rather tall order. Logic-based query languages are difficult to troubleshoot when you don't get the results you expected. It's kind of like a formalized version of Google: you get results, but you don't know if they are the best results, you don't know what you are missing, and you often don't know why you got what you did. You have to have some kind of discipline and structure to the data in order to understand and troubleshoot results (at least for mortals and non-Sheldons). Some say relational is "too stiff" for some uses, but there is the Dynamic Relational proposal that gives it flexibility without abandoning relational and SQL. (Some argue it's not technically relational, which I don't agree with, but that issue doesn't change the similarity to existing RDBMS & SQL conventions.) As far as relational-based alternatives to SQL, consider these discussions: http://wiki.c2.com/?HowOtherQueryLanguagesAddressSqlFlaws http://wiki.c2.com/?HowOtherQueryLanguagesAddressSqlFlaws http://wiki.c2.com/?QueryLanguageComparison http://wiki.c2.com/?QueryLanguageComparison http://wiki.c2.com/?ExperimentalQueryLanguageComparison http://wiki.c2.com/?ExperimentalQueryLanguageComparison