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

Relational is more than SQL

fauna.com

Post reply on HN
Print view View original

91–100 of 177 posts

Re: Relational is more than SQL

#91

Post by bob1029 »

slotrans wrote: post #86

Fixed schemas are good. Document stores are bad. SQL is good. Stop doing this nonsense. It's a step backwards. As the intro points out, hierarchical and graph DBs came first , and relational was built in part to solve their problems. Document DBs just bring those problems back.

> Fixed schemas are good.

I recall getting into an argument recently (perhaps on HN) wherein the central thesis for why SQL is bad is because the schema is "difficult" to change relative to a document store or other no-SQL abstraction.

If you don't have a clear idea of what the representative SQL schema might be for your problem or business (say, within ~80%+ certainty), one may argue you should not be writing any software until you've further clarified things with business stakeholders.

I strongly believe that virtually all evil which emerges from practical software engineering comes out of this "flexible schema" bullshit. If the business is certain of the shape of their problem, there is almost certainly a fixed schema that can accommodate. There are very few problem domains which cannot be coaxed into a strict SQL schema.

Re: Relational is more than SQL

#92

Post by ttfkam »

bazoom42 wrote: post #83
ttfkam wrote: post #69

Earlier quoted context omitted.

It's not 1992 anymore. https://youtu.be/8Fb5Qgpr03g?si=Jc7dpuVgws3POiXA It may upset someone's sense of "purity", but the SQL standard and thoughts about the relational model have long since moved on from this dogmatic view of atoms, and no, foreign keys can't perfectly model what folks need. Eventually the rubber hits the road, theory and practice diverge, and different approaches are clearly needed. There is a plac…

I belive in using the right tool for the job, and this might somtimes be document databases, key-value stores, xml or json values or whatever is needed to solve the problem. But let me point out that hierachical databases (which document databases, xml etc are variants of) predate the relational model (and certainly predate Dates work) so it it worth to be aware of the challenges and limitations which caused the deve…

> I belive in using the right tool for the job

And more of these tools (RDBMSs) are able to perform more jobs. There's definitely use cases for correlating parts of documents with traditional relational data. Quite often there's no need to choose between a relational database engine and a document database engine when the engines support both and more.

Hybrids tend to blur the lines for definitions.

Re: Relational is more than SQL

#93

Post by sebastianz »

wackget wrote: post #87
ttfkam wrote: post #68

Earlier quoted context omitted.

The syntax comparison section will likely sour a lot of viewers who already know SQL. You try too hard to highlight how easy and terse PRQL is by putting comma-separated items on their own lines but in SQL you put each item on separate lines. It may be typical of many SQL users and formatters, but it leaves a poor taste in the mouth that you aren't interested in an actual comparison but in marketing. For those who al…

Yeah the syntax comparison is deliberately misleading. They style it as "4 lines vs 10 lines!" when it's actually 4 lines vs 4 lines. # PRQL from employees select {id, first_name, age} sort age take 10 # Misleading SQL SELECT id, first_name, age FROM employees ORDER BY age LIMIT 10 # Actual SQL SELECT id, first_name, age FROM employees ORDER BY age LIMIT 10 The join example is similarly deceptive: # PRQL from employe…

It is also (for me) quite a bit noisier and less readable than SQL. The join example has multiple different syntactic symbols, for no clear intuitive reason (= vs ==, {} vs (), side:left vs p=positions).

Re: Relational is more than SQL

#94

Post by j-a-a-p »

wackget wrote: post #87
ttfkam wrote: post #68

Earlier quoted context omitted.

The syntax comparison section will likely sour a lot of viewers who already know SQL. You try too hard to highlight how easy and terse PRQL is by putting comma-separated items on their own lines but in SQL you put each item on separate lines. It may be typical of many SQL users and formatters, but it leaves a poor taste in the mouth that you aren't interested in an actual comparison but in marketing. For those who al…

Yeah the syntax comparison is deliberately misleading. They style it as "4 lines vs 10 lines!" when it's actually 4 lines vs 4 lines. # PRQL from employees select {id, first_name, age} sort age take 10 # Misleading SQL SELECT id, first_name, age FROM employees ORDER BY age LIMIT 10 # Actual SQL SELECT id, first_name, age FROM employees ORDER BY age LIMIT 10 The join example is similarly deceptive: # PRQL from employe…

PRQL is a solution in search of a problem. Lacking such, the problem had to be fabricated.

Re: Relational is more than SQL

#95

Post by pphysch »

lcnPylGDnU4H9OF wrote: post #88
slotrans wrote: post #86

Fixed schemas are good. Document stores are bad. SQL is good. Stop doing this nonsense. It's a step backwards. As the intro points out, hierarchical and graph DBs came first , and relational was built in part to solve their problems. Document DBs just bring those problems back.

At this point, one chooses the solution for their problem. The reason the fads occur is that a person who vaguely understands both the problem and the solution will write a blog post which happens to go viral talking about how the solution will solve all problems. NoSQL databases aren’t unilaterally worse than relational ones. They just solve different problems.

> NoSQL databases aren’t unilaterally worse than relational ones. They just solve different problems.

I can't prove this, but I assert that a relational database that has solid JSON+text support (e.g. Postgres) is on much better footing than a NoSQL DB that attempts to implement a true relational model.

One is a adding a special new datatype, the other is trying to add an entire paradigm.

Just use Postgres. If you do need to migrate to Mongo for some reason, dumping your tables into JSON isn't the end of the world.

Re: Relational is more than SQL

#96

Post by marcosdumay »

dagss wrote: post #2

Nitpick, but relational does not mean joins, it means tables/rows of tuples. A "relational document database" which is the slogan of Fauna it seems is a contradiction in terms.

Whatever you want to point from theory, the one single distinctive feature of the relational model is the "mostly free" interdependency between the relations. AKA, the fks and joins.

Re: Relational is more than SQL

#97

Post by setr »

danielvaughn wrote: post #46
leeuw01 wrote: post #35

Earlier quoted context omitted.

This +1. I've been burned before when using ORMs which translate simple-looking queries to terribly inneficient SQL statements underwater.

Yeah I’m a web dev, and recently I found out the most popular JS ORM doesn’t produce joins. It’ll just execute multiple queries in sequence. I don’t know how common that is in the ORM landscape but for me that’s a deal breaker.

That’s just a direct result of lazy loading — if you don’t grab the related objects in the initial query, then there’s no joins to be had.

Most ORMs do lazy loading by default, but also have a way of doing eager loading — either requiring the nested object to always be loaded as well, or dropping down to some pseudo-sql.

In c#/EFCore, I always prefer to avoid lazy loading and just write LINQ, and just use the ORM to map the resultset back to objects

Re: Relational is more than SQL

#98

Post by lolinder »

snthpy wrote: post #12

Disclaimer: I'm a core contributor to PRQL [1] and post about it a lot on HN. Apologies for jumping in on other people's threads, but for people interested in the headline, PRQL might be of interest. At PRQL[1] we believe that SQL is a combination of two things: 1. Relational Algebra, which is eternal because it's just maths, and 2. A language designed in the 70s that looks like COBOL. When people say that SQL will n…

SQL will never die for the same reason that JavaScript will never die: because it's built in to all major database engines.

In both cases, any other language will be starting as a second class citizen that has to compile to SQL/JS. During this phase of a new language's lifetime, it is either a surface-level syntactic change (a la Coffeescript) that provides no objective improvement, or it has to compile its simple semantic structures into opaque SQL/JS structures that will be off the beaten path and therefore not highly optimized by the runtime. Neither will reach sufficient adoption to become a first-class citizen in a major existing platform.

TypeScript succeeded where others failed because it provided much-needed static analysis while keeping the changes minimal enough that it's completely obvious what the runtime code will look like, so there are no unexpected performance gotchas. SQL, on the other hand, doesn't really need a TypeScript because SQL is highly statically analyzable by nature.

It's not that I don't believe we could do with an improvement on SQL, but I really don't see a realistic path forward for a replacement.

Re: Relational is more than SQL

#99

Post by paulddraper »

lolinder wrote: post #98
snthpy wrote: post #12

Disclaimer: I'm a core contributor to PRQL [1] and post about it a lot on HN. Apologies for jumping in on other people's threads, but for people interested in the headline, PRQL might be of interest. At PRQL[1] we believe that SQL is a combination of two things: 1. Relational Algebra, which is eternal because it's just maths, and 2. A language designed in the 70s that looks like COBOL. When people say that SQL will n…

SQL will never die for the same reason that JavaScript will never die: because it's built in to all major database engines. In both cases, any other language will be starting as a second class citizen that has to compile to SQL/JS. During this phase of a new language's lifetime, it is either a surface-level syntactic change (a la Coffeescript) that provides no objective improvement, or it has to compile its simple se…

While I mostly agree, there is a bit of Stockholms syndrome.

A lot of people don't know what they even could be missing.

For example, there is no succinct way of writing an antijoin in SQL .

The MERGE command has only been implemented by some engines due to (IIRC) concurrency concerns/ambiguities.

ANSI SQL JSON operations have improved but are still clunky.

Boolean NULL and IN is a clusterf of footguns.

Etc.

Re: Relational is more than SQL

#100

Post by lolinder »

paulddraper wrote: post #99
lolinder wrote: post #98

Earlier quoted context omitted.

SQL will never die for the same reason that JavaScript will never die: because it's built in to all major database engines. In both cases, any other language will be starting as a second class citizen that has to compile to SQL/JS. During this phase of a new language's lifetime, it is either a surface-level syntactic change (a la Coffeescript) that provides no objective improvement, or it has to compile its simple se…

While I mostly agree, there is a bit of Stockholms syndrome. A lot of people don't know what they even could be missing. For example, there is no succinct way of writing an antijoin in SQL . The MERGE command has only been implemented by some engines due to (IIRC) concurrency concerns/ambiguities. ANSI SQL JSON operations have improved but are still clunky. Boolean NULL and IN is a clusterf of footguns. Etc.

Oh, I agree! SQL is far from optimal, as is JS. My thoughts are more about the feasibility of a replacement than the need for one.

US electrical outlets are also highly flawed, but we're never going to replace them either. Standards, once entrenched, are nearly impossible to uproot.

Post reply on HN