Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why SQL is beating NoSQL, and what this means for the future of data

blog.timescale.com

Post reply on HN
Print view View original

201–210 of 310 posts

Re: Why SQL is beating NoSQL, and what this means for the future of data

#201

Post by magoghm »

coldtea wrote: post #178
pjungwir wrote: post #25

I've always found it a little funny that SQL was originally designed for non-programmers, sort of like AppleScript. I used to think neither of those panned out, but in fact there really are a lot of smart not-programmers who can use it. At a company I work with many of the support staff have been learning SQL to help customers pull reports from our data warehousey reporting database. So maybe the article is onto some…

> I've always found it a little funny that SQL was originally designed for non-programmers That's not true.

"2. SQL is intended to be accessible to users without formal training in mathematics or computer programming. It is designed to be typed on a keyboard. Therefore it is framed in familiar English keywords, and avoids specialized mathematical concepts or symbols." http://researcher.ibm.com/researcher/files/us-dchamber/SQL-e...

Re: Why SQL is beating NoSQL, and what this means for the future of data

#202

Post by jeremiep »

zimablue wrote: post #200

It feels like everyone mixes relational databases with SQL in discussions. Relational databases are fine but SQL is disgusting. It's a query language that's very hard to parse or generate and has multiple incompatible variants. Ironically the Lambda calculus version looks much better, I'd never seen those before. I wish we'd go back to that as default, unify around a standard and expose block text SQL as an extra for…

The one downside I see with SQL is that its a string. Would it be a data structure instead it would be incredibly easier to manipulate, without third party query builders. Even without that its still more convenient than most NoSQL.

Still, Datalog as implemented by Datomic is a breath of fresh air.

Re: Why SQL is beating NoSQL, and what this means for the future of data

#203

Post by ojosilva »

kazagistar wrote: post #142
ojosilva wrote: post #136

Earlier quoted context omitted.

>I think the bigger issue is that you can use an RDBMS to do NoSQL-like things, such as key-value stores, with the flexibility to structure your data if you need that later. So why not start with a relational database? I've tried that in the past and failed miserably. 1) values in a key-value table will endup needing to hold nested data structures, such as a JS object/hash. Ie. mykey={...} 2) turning values to JSON (…

1. Postgres has a json and jsonb datatype specifically to be your values. 2. It has built in query and modification tools that can manage the nested objects and array and whatnot. 3. It let's you build indexes to help with all this, including reverse indexes for asking something like "is this string in the array inside this object". 4. You don't have to specify your schema in sone horrid way, you can just throw what…

Postgres JSON(B) falls nearly in the same category. Do not use Postgres as a key value store, use a KV store for that.

Postgres JSON is great for storing the original JSON data coming from external APIs and Webhooks, such as Stripe payments. But it's not a silver bullet and really not a first class citizen. SQL query syntax for JSON data is awful, non-standard and requires casting types, which defeats the purpose of schemaless. I believe Postgres JSON types solve a different use case: an app based on a relational schema that needs to store JSON structures eventually.

I don't recommend starting off your app basing it on Postgres JSON. Use the full relational Postgres instead and do it right from the start.

Re: Why SQL is beating NoSQL, and what this means for the future of data

#204

Post by marrs »

SmellTheGlove wrote: post #18
Clubber wrote: post #12

Earlier quoted context omitted.

>So why not start with a relational database? I asked the same question. The biggest reason I've heard is RDBMS's don't horizontally scale well, meaning you can't easily have 50 replicated nodes across the globe and expect it to perform well, or setup easily, because it's fairly complicated with an RDBMS. There's things like Oracle's grid or SQL's high availability clusters, but they get complicated fast, particularl…

> It's a Google/Twitter size problem that most industries wouldn't have, but since it's the new shiny thing, you know how that goes. You nailed it on both points. Very few organizations are going to need that kind of scale, but many want to think that they will! Even when you get to horizontal scaling, you can simply replicate what needs to be replicated. Key-value is really just a subset of relational data, right? I…

    Very few organizations are going to need that kind of
    scale, but many want to think that they will!
Further to that point, many software engineers know that NoSQL is a bad fit for their organisation but use it anyway because they wish to gain the experience required to work with Big Data in the future.

Re: Why SQL is beating NoSQL, and what this means for the future of data

#206

Post by zimablue »

jeremiep wrote: post #202
zimablue wrote: post #200

It feels like everyone mixes relational databases with SQL in discussions. Relational databases are fine but SQL is disgusting. It's a query language that's very hard to parse or generate and has multiple incompatible variants. Ironically the Lambda calculus version looks much better, I'd never seen those before. I wish we'd go back to that as default, unify around a standard and expose block text SQL as an extra for…

The one downside I see with SQL is that its a string. Would it be a data structure instead it would be incredibly easier to manipulate, without third party query builders. Even without that its still more convenient than most NoSQL. Still, Datalog as implemented by Datomic is a breath of fresh air.

It's more than just being a string though, it's the multiple incompatible versions and the stunted mini language of it's own. A good solution would be able to run arbitrary expressions in some "real" programming language. It also in my experience doesn't seem to deliver on its central premise of converting declarative expressions to fast operations. So often in a SP I've had to force a write to an intermediate table to jimmy the execution plan. I think it's like excel, it's not considered good because the thing itself is good it seems good because the thing it does is very useful (lightweight interactive dataflow programming, talking to relational databases) and it has a near monopoly. LINQ is really cool but doesn't exist in python (macropython has an unused attempt PINQ I think). Probably because a) SQL is bad b) only MS actually has the definition of the mssql language!

Re: Why SQL is beating NoSQL, and what this means for the future of data

#207

Post by matwood »

hvidgaard wrote: post #134
craigkerstiens wrote: post #53

I don't think the article could have said it much better. SQL is super powerful and makes much sense in so many ways. Nearly all apps have a relational structure to them and SQL is a reasonable way to interact with them. Some of my favorite conversations from the Postgres community 5-6 years back were when they were talking about a time when Postgres was being disrupted. The gray bearded DBAs (Hi Berkus and others) w…

> SQL has never been a particularly elegant language I hear that often. But SQL is close to a 1-to-1 mapping with sets of data. It's refreshing to use something as math like when programming. I find that elegant.

I agree. Of course any language has its warts, but when dealing with data I don't know of a better language than SQL.

Re: Why SQL is beating NoSQL, and what this means for the future of data

#208

Post by matwood »

unclebucknasty wrote: post #103
craigkerstiens wrote: post #53

I don't think the article could have said it much better. SQL is super powerful and makes much sense in so many ways. Nearly all apps have a relational structure to them and SQL is a reasonable way to interact with them. Some of my favorite conversations from the Postgres community 5-6 years back were when they were talking about a time when Postgres was being disrupted. The gray bearded DBAs (Hi Berkus and others) w…

I think I'm one of those graybeards. I see it in so many things tech. It's a pattern, and once you've seen it repeat a half-dozen times and also gain a depth of experience over that time, you can actually recognize when something represents genuine progress vs yet another passing fad. Spoiler alert: those that are most rabidly promoted are often the latter. But, if you try to raise the point in the midst of the lates…

My beard does in fact have some gray ;) , and I've never stopped beating the SQL drum. One other thing you learn is that data always outlive whatever app is using it today. I want my data to be stored in a safe way, and self contained apart from whatever flavor of the month app is generating/using it today. RDBMSs are perfect for this.

Re: Why SQL is beating NoSQL, and what this means for the future of data

#209

Post by [deleted] »

Wildgoose wrote: post #166
wolco wrote: post #108

Earlier quoted context omitted.

It is greybeard or graybeard?

American spelling is gray, English/UK spelling is grey. Easy way to remember is use "a" for "American" in the American spelling, and "e" (for English) in UK (and presumably the rest of the Commonwealth).

[deleted]
Post reply on HN