Comment by cryptonector | Hacker News Reader

Comment by cryptonector | Hacker News Reader

Parent Full thread

Typically there are two arguments for NoSQL: "no SQL!" (i.e., "the SQL language is so ugly, difficult, and painful") and "no ACID" (i.e., eventually consistent, hopefully, maybe).

The first one is always demonstrated to be a terrible argument when someone creates a SQL alike for whatever NoSQL we're talking about.

The second one has been a more durable argument. But transactional semantics clearly are independent of query language! And technologies like Lustre and Spanner show that one can still have some measure of traditional transactional semantics in distributed systems (filesystems and databases, respectively). There are many applications where some degree of "eventually-consistent" is a great tool for making them scale, but this is often a function of what can be done in the event that inconsistencies create problems (e.g., a store selling more items of some product than it has available, a case where the store can refund the customer or delay delivery).

I'm extremely skeptical of NoSQLs, as you can tell. I would say that NoSQLs have NoPLACE. (Certainly as to that first argument.)

I'm also extremely skeptical of ORMs. So far as I can tell ORMs only ever add a layer of headaches. They seem to aim for simplifying the DB experience for developers and users, but the moment you step out of the small world of queries made simpler by the ORM... you're in for a world of hurt.

I'd actually quite like a relational database with a language that isn't SQL. I find SQL's syntax pretty irregular and awkward (e.g. update having a different syntax from insert), find the tools available for abstracting and composing queries (views) underwhelming and hate that schemas aren't declarative.

The first complaint derives largely from the SQL language being intended to read link English text. Languages like this show up regularly, seemingly based on the misconception that syntax is what's hard about programming. Most of them fail, as they should. SQL didn't, because it was tied to the exceptionally useful relational database.

The second is best illustrated by showing an alternative approach as an example: Korma for Clojure (http://sqlkorma.com/). It's easy to compose queries from simpler queries, just as we compose functions from simpler functions. Views provide some of this.

The third, if it's solvable would make using relational databases much nicer. Instead of schemas being manually-created diffs full of imperative statements like create and alter, make them declarative and have software generate the diff. If transformations on the data itself are required between versions, require it to include a pure function describing said transformation. By default, require a function to transform it back as well unless it explicitly says what data is to be discarded.

>I'd actually quite like a relational database with a language that isn't SQL

Perhaps you want a Prolog. :)

> I'd actually quite like a relational database with a language that isn't SQL.

They exist, e.g., Dataphor, Rel, etc. But it's hard to displace SQL.

I don't find most SQL too bad at all... where it gets weird is when you're dealing with more exotic data types and the database vendor's specific details in interacting with them. XML/JSON interaction in SQL databases tends to be particularly mind bending.

I do prefer the more fluent-like interfaces though... MongoDB and RethinkDB in node for example, or using the LINQ extension methods with Entity Framework (not LINQ syntax itself, which I find much more difficult). Though with LINQ, it's often interesting how twisted what gets queried from the data source can be vs. what you actually need... but that's a problem with most ORMs.

I do find that SQL queries with Node/JS adapters is pretty damned natural compared to any ORM for Java or C# imo...

You don't like languages that the average human being can make sense out of but you do like Clojure? Did I read that right?

Then, "make them declarative and have software generate the diff". So you want the benefits of relational data without the pain, is that it? Why not use Hibernate like the oh so wise ones have told us to use only to now realize trying to bend relational tools into what a language designer's ideas are is maybe, probably, not the best idea after all and perhaps the reason that SQL and relational databases have withstood the test of time and Hibernate is on the road to death is that SQL and relational design were extremely, unabashedly well thought out and designed in the first place.

You don't like languages that the average human being can make sense out of but you do like Clojure? Did I read that right?

You read that almost right. See, I don't think the average human who's fluent in English but not SQL will be able to properly understand anything but the most basic queries. Sure,

    SELECT * from users where username = 'remotehack';

is going to mostly make sense to the average person (but what's the * and ; for?), but then so will

    (select users (where {:username "remotehack"}))

The brackets won't make sense, of course, but we're talking about reading it, not writing, and they're not terribly important to that.

Now, give that same average person

    Select Distinct On (u.username, u.email)
         u.username
        ,u.email
        ,l.browser
        ,l.login_time
    From users u
    Join logins l On l.username = u.username
    Order By u.username, login_time Desc

and do you really think they'll have any idea what to expect that to return? This no longer reads like English.

And no, when I ask for declarative schemas, I'm not asking for ORM. I'm asking for a system where I say what the schema is instead of saying how to create it, just as I say what data I want rather than how to retrieve it. This is not incompatible with any of the fundamental concepts of relational databases.

Reply on news.ycombinator.com