Hacker News Reader

Comment by obi1kenobi | Hacker News Reader

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

[2]: https://blog.kensho.com/compiled-graphql-as-a-database-query...

[3]: https://blog.kensho.com/database-agnostic-querying-is-unavoi...

[4]: https://github.com/obi1kenobi/graphql-compiler-cross-db-exam...

View on HN

I'm building a relational lang (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...

Speaking of Tcl, there's TclRAL, a C-based Tcl extension that implements the Relational Algebra.

https://wiki.tcl-lang.org/page/TclRAL

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

Ja!

In fact "TablaM" come to sound like "Kablam!" 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

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.

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.

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.

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.... - neither did the original version of LDAP (RFC 1487 https://tools.ietf.org/html/rfc1487 RFC 1488 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 (1996) and it’s just a rendering of the ASN.1 structure.

I thought SQL descended relatively straightforwardly from SEQUEL.

> 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.

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...

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();

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.

Reply on news.ycombinator.com