7 ms·

I have to question the "relational" part. SQL is an absolutely massive language, to the point where "we support SQL" is almost an empty statement because there'

I have to question the "relational" part. SQL is an absolutely massive language, to the point where "we support SQL" is almost an empty statement because there's no single SQL to support. While revamping the database, consider a smaller query language. I built a GraphQL-based database query language in my GraphQL compiler project[1], and it's been a huge success at my company so far[2][3]. Here's a demo of cross-database querying with it, if you're curious [4]. [1]: https://github.com/kensho-technologies/graphql-compiler https://github.com/kensho-technologies/graphql-compiler [2]: https://blog.kensho.com/compiled-graphql-as-a-database-query-language-72e106844282 https://blog.kensho.com/compiled-graphql-as-a-database-query... [3]: https://blog.kensho.com/database-agnostic-querying-is-unavoidable-at-scale-18895f6df2f0 https://blog.kensho.com/database-agnostic-querying-is-unavoi... [4]: https://github.com/obi1kenobi/graphql-compiler-cross-db-example https://github.com/obi1kenobi/graphql-compiler-cross-db-exam...

dragonwriter 6y ago
> have to question the "relational" part. SQL is an absolutely massive language SQL is not the same thing as relational. Relational is a model, SQL is a language which (arguably, quite loosely) fits that model.
- lgas 6y ago
  Yes and there are in fact better languages for dealing with relational data than SQL, eg. https://en.wikipedia.org/wiki/D_(data_language_specification) https://en.wikipedia.org/wiki/D_(data_language_specification...
emilsedgh 6y ago
I'm not really an expert on the field. But, have you considered that maybe SQL is massive for good reasons? The subset of SQL that covers majority of use cases is actually small and probably mostly covered by the standard. All the rest of SQL which makes it a massive beast is for all those cases where adding the logic to the database would've been the most efficient for all those who need that extra bit of efficiency.
- zoltar 6y ago
  It's slightly more likely that modern SQL is the byproduct of several query language specifications accelerated to ludicrous speeds and set to collide with each other. Out one end of the apparatus, SQL-86 emerged. A little known fact about this experiment: the residue splattered along the interior of the apparatus was recovered and named LDAP.
  - fanf2 6y ago
    LDAP is a stripped down version of the X.500 directory, but I wasn’t aware that had anything to do with SQL. X.500 is hierarchical, not relational, and it doesn’t have a query language as such - http://sec.cs.kent.ac.uk/x500book/Chapter.5/Chapter5b.htm#5.10%20THE%20SEARCH%20OPERATION http://sec.cs.kent.ac.uk/x500book/Chapter.5/Chapter5b.htm#5.... - neither did the original version of LDAP (RFC 1487 https://tools.ietf.org/html/rfc1487 https://tools.ietf.org/html/rfc1487 RFC 1488 https://tools.ietf.org/html/rfc1488 https://tools.ietf.org/html/rfc1488). The text representation of filters didn’t turn up until RFC 1960 https://www.rfc-editor.org/rfc/rfc1960.html https://www.rfc-editor.org/rfc/rfc1960.html (1996) and it’s just a rendering of the ASN.1 structure. I thought SQL descended relatively straightforwardly from SEQUEL.
- setr 6y ago
  I think SQL is massive because of two major reasons: 1. It has a highly inconsistent, non-generalized syntax 2. It tries to reuse the language for everything -- from schema specification, to querying, to administration, to query engine hints, to procedural language definitions The RDBMS in total is a highly complex system, but SQL adds a lot of accidental complexity on top of it. Also for a new DB, you hardly need to support the whole suite of features to produce a useful system -- you just need to constrain the recommended usecases. See SQLite for the quintessential example -- they dropped MVCC and a lot of management/multi-tenancy features as they targetted a surprisingly large niche. As it turns out, there's a wide variety of data management needs -- SQL is often a beast because most RDBMS's have a goal of targetting all of them.
mamcx 6y ago
I'm building a relational lang (http://tablam.org http://tablam.org) so this is close to my interests. SQL is not just massive, it have grown past it actual capabilities and original purposes without fix or clean it, then ALSO need to be the interface for some of the most complex piece of software (rdbms) and support the needs of a multitude of features, frameworks and languages. Is like html/css/js. Going to basics, the relational model is fairly simple, and you can spice it with functional and/or procedural features to round it and still keep it very small. So yes, I think it can be done MUCH better than SQL and still do MUCH more than it can right now... P.D: My language TablaM (will!)is basically this plus a little of array programming. You can fit very well the relational model in a lisp/tcl/datalog like environment with a small core that is very expressive...
- emmanueloga_ 6y ago
  For the spanish speakers on this thread, the name "TablaM" reminds me of this: [1] :-p 1: https://www.youtube.com/watch?v=8ktYyme_sUw https://www.youtube.com/watch?v=8ktYyme_sUw
  - mamcx 6y ago
    Ja! In fact "TablaM" come to sound like "Kablam!" https://www.youtube.com/watch?v=9glnVMq1xrE https://www.youtube.com/watch?v=9glnVMq1xrE, a nickelodeon weird program of the past (when it do a lot of cool things). I have a habit of put weird names to my projects... Then I morph into tablam, and later in the game I create a pseudo-plausible rationalization where "Tabla (spanish)" == "Table" and M is for "Multi-paradigm, -platform, -dimension, etc" that is the one explanation I will use in case get serious people asking me :) P.D: I have a video for this at https://www.youtube.com/watch?v=Qs6byLBqyR4 https://www.youtube.com/watch?v=Qs6byLBqyR4
- blacksqr 6y ago
  Speaking of Tcl, there's TclRAL, a C-based Tcl extension that implements the Relational Algebra. https://wiki.tcl-lang.org/page/TclRAL https://wiki.tcl-lang.org/page/TclRAL
throwaway_pdp09 6y ago
Why is it 'massive'? I don't think it is. Compared to say C++, or programming in python where the language is smallish but the libraries considerable, I can't see why you say that.
xixixao 6y ago
I agree. I’d focus on a graph database, as it is a better model for most things, and can act as a dumb table too. interestingOnes = Pokemons.queryAll() .whereColor(P.equals(“grass”)) .queryWorstEnemy() .whereColor(P.notEquals(“fire”)) .get();

dragonwriter 6y ago

> have to question the "relational" part. SQL is an absolutely massive language SQL is not the same thing as relational. Relational is a model, SQL is a language which (arguably, quite loosely) fits that model.

lgas 6y ago
Yes and there are in fact better languages for dealing with relational data than SQL, eg. https://en.wikipedia.org/wiki/D_(data_language_specification) https://en.wikipedia.org/wiki/D_(data_language_specification...

emilsedgh 6y ago

I'm not really an expert on the field. But, have you considered that maybe SQL is massive for good reasons? The subset of SQL that covers majority of use cases is actually small and probably mostly covered by the standard. All the rest of SQL which makes it a massive beast is for all those cases where adding the logic to the database would've been the most efficient for all those who need that extra bit of efficiency.

zoltar 6y ago
It's slightly more likely that modern SQL is the byproduct of several query language specifications accelerated to ludicrous speeds and set to collide with each other. Out one end of the apparatus, SQL-86 emerged. A little known fact about this experiment: the residue splattered along the interior of the apparatus was recovered and named LDAP.
- fanf2 6y ago
  LDAP is a stripped down version of the X.500 directory, but I wasn’t aware that had anything to do with SQL. X.500 is hierarchical, not relational, and it doesn’t have a query language as such - http://sec.cs.kent.ac.uk/x500book/Chapter.5/Chapter5b.htm#5.10%20THE%20SEARCH%20OPERATION http://sec.cs.kent.ac.uk/x500book/Chapter.5/Chapter5b.htm#5.... - neither did the original version of LDAP (RFC 1487 https://tools.ietf.org/html/rfc1487 https://tools.ietf.org/html/rfc1487 RFC 1488 https://tools.ietf.org/html/rfc1488 https://tools.ietf.org/html/rfc1488). The text representation of filters didn’t turn up until RFC 1960 https://www.rfc-editor.org/rfc/rfc1960.html https://www.rfc-editor.org/rfc/rfc1960.html (1996) and it’s just a rendering of the ASN.1 structure. I thought SQL descended relatively straightforwardly from SEQUEL.
setr 6y ago
I think SQL is massive because of two major reasons: 1. It has a highly inconsistent, non-generalized syntax 2. It tries to reuse the language for everything -- from schema specification, to querying, to administration, to query engine hints, to procedural language definitions The RDBMS in total is a highly complex system, but SQL adds a lot of accidental complexity on top of it. Also for a new DB, you hardly need to support the whole suite of features to produce a useful system -- you just need to constrain the recommended usecases. See SQLite for the quintessential example -- they dropped MVCC and a lot of management/multi-tenancy features as they targetted a surprisingly large niche. As it turns out, there's a wide variety of data management needs -- SQL is often a beast because most RDBMS's have a goal of targetting all of them.

mamcx 6y ago

I'm building a relational lang (http://tablam.org http://tablam.org) so this is close to my interests. SQL is not just massive, it have grown past it actual capabilities and original purposes without fix or clean it, then ALSO need to be the interface for some of the most complex piece of software (rdbms) and support the needs of a multitude of features, frameworks and languages. Is like html/css/js. Going to basics, the relational model is fairly simple, and you can spice it with functional and/or procedural features to round it and still keep it very small. So yes, I think it can be done MUCH better than SQL and still do MUCH more than it can right now... P.D: My language TablaM (will!)is basically this plus a little of array programming. You can fit very well the relational model in a lisp/tcl/datalog like environment with a small core that is very expressive...

emmanueloga_ 6y ago
For the spanish speakers on this thread, the name "TablaM" reminds me of this: [1] :-p 1: https://www.youtube.com/watch?v=8ktYyme_sUw https://www.youtube.com/watch?v=8ktYyme_sUw
- mamcx 6y ago
  Ja! In fact "TablaM" come to sound like "Kablam!" https://www.youtube.com/watch?v=9glnVMq1xrE https://www.youtube.com/watch?v=9glnVMq1xrE, a nickelodeon weird program of the past (when it do a lot of cool things). I have a habit of put weird names to my projects... Then I morph into tablam, and later in the game I create a pseudo-plausible rationalization where "Tabla (spanish)" == "Table" and M is for "Multi-paradigm, -platform, -dimension, etc" that is the one explanation I will use in case get serious people asking me :) P.D: I have a video for this at https://www.youtube.com/watch?v=Qs6byLBqyR4 https://www.youtube.com/watch?v=Qs6byLBqyR4
blacksqr 6y ago
Speaking of Tcl, there's TclRAL, a C-based Tcl extension that implements the Relational Algebra. https://wiki.tcl-lang.org/page/TclRAL https://wiki.tcl-lang.org/page/TclRAL

throwaway_pdp09 6y ago

Why is it 'massive'? I don't think it is. Compared to say C++, or programming in python where the language is smallish but the libraries considerable, I can't see why you say that.

xixixao 6y ago

I agree. I’d focus on a graph database, as it is a better model for most things, and can act as a dumb table too. interestingOnes = Pokemons.queryAll() .whereColor(P.equals(“grass”)) .queryWorstEnemy() .whereColor(P.notEquals(“fire”)) .get();