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

Build your next app with a graph database

dgraph.io

Post reply on HN
Print view View original

31–40 of 58 posts

Re: Build your next app with a graph database

#31

Post by madrox »

the_duke wrote: post #25

I'm currently on my first project involving a graph database . Dgraph coincidentally, and I somewhat like the product. But this is a horrible article that would immediately leave a bad taste in my mouth if I were researching the product. It boils down to a shallow dismissal of relational databases that does not have much more substance than "Relational dbs are old and bad! Graphs are awesome because relations and que…

I'm pleased to hear so many comments saying this.

I don't think this style of writing is appropriate for engineering. This is computer science, and even in marketing posts like this one we should be reading analysis of performance benchmarks along with pros and cons.

I'm immediately skeptical of technology that takes this marketing approach.

Re: Build your next app with a graph database

#32

Post by AnimalMuppet »

staticassertion wrote: post #22
chvid wrote: post #18

From the article: "Relational databases: a software engineering fail ... That you were taught relational databases at all is an accident. It's simply that they are an early tech that became widely used, so your teacher knows about them, and, importantly, that they are a dream to teach." What. Really?

Is this really so hard to believe? Lots of things that are "Default" are just that way for historic purposes. One example, and I say this as someone who's generally a fan of the language, would be Java - it's taught in so many schools, because it's taught in so many schools . Everyone says things like "You don't need a graphdb" because their default assumption is that there is a cost relative to rdbms, that's the bia…

There were two lines held up for mocking.

The first one described relational DBs as a software engineering fail. That's patently absurd. (If that's failure, what would success look like?)

You addressed the second one, which is slightly less absurd. You were taught relational DBs because they are enormously widely used. And why are they used so widely? Because they work.

What the article should be saying is, "Here's this approach that works better than relational, and here's how and why it works better." Mocking relational DBs, as if they had been a failure, just makes the authors look clueless.

Re: Build your next app with a graph database

#33

Post by wayneftw »

I learned basic SQL in a few weeks in my twenties. The knowledge of it lasted me 2 decades.

I regularly learn new technologies and I can use them immediately. Things like ELK (ElasticSearch), React, Golang, modern JS.

For some reason, trying to learn DGraph and graph databases in general has always been very difficult for me. I wanted to like them, but just about everything I want to do can be done more easily with a relational database. And RDBMS tools mostly just work. Setting up DGraph was a freaking nightmare. I think you need a minimum of 3 Docker containers to run it and I'm not even sure what each container is actually responsible for.

If they want people to use this, I think DGraph should make their stuff easier to use and give us some better tools.

Re: Build your next app with a graph database

#34

Post by pantaloony »

wenc wrote: post #17

I've been looking at Hasura [1] due to the accolades it's gotten on HN. It throws up a GraphQL interface to PostgreSQL. I wonder if anyone can speak to how Hasura's approach compares to designing an architecture around a pure graph database? [1] https://hasura.io/how-hasura-works/

GraphQL isn’t particularly “graphy” nor does it have much to do (necessarily) with graph databases. Its name is, for the reason that it continually generates that sort of confusion, pretty bad.

Re: Build your next app with a graph database

#35

Post by fractallyte »

znpy wrote: post #6

It's a shame that almost no one knows or uses Versant OODBMS (object-oriented database management system). As the name suggest it's object oriented and queries return graphs of objects. It's heavily multi-threaded and has been around since 1989 (iirc). The only big downside (besides being proprietary) is that it's almost impossible to scale out (horizontally). But it scales enormously well vertically (throw resources…

There's also Gemstone, a proprietary Smalltalk object database (https://gemtalksystems.com/). You do all your coding within the database, so it really blurs the distinction between data and code.

Magma is a rather nice open source Smalltalk database (https://wiki.squeak.org/squeak/2665), available for Squeak and Pharo.

Re: Build your next app with a graph database

#36

Post by wenc »

pantaloony wrote: post #34
wenc wrote: post #17

I've been looking at Hasura [1] due to the accolades it's gotten on HN. It throws up a GraphQL interface to PostgreSQL. I wonder if anyone can speak to how Hasura's approach compares to designing an architecture around a pure graph database? [1] https://hasura.io/how-hasura-works/

GraphQL isn’t particularly “graphy” nor does it have much to do (necessarily) with graph databases. Its name is, for the reason that it continually generates that sort of confusion, pretty bad.

You're correct -- it's more of a query-language-ish alternative to REST.

However, it does let one work with hierarchical data structures that map more closely to the JSONish mental model that most app developers have, rather than with pure SQL tabular data structures which have to be object-mapped.

I'd imagine most developers just want that, rather than capabilities for doing relationship/connection queries which real graph databases specialize in.

Re: Build your next app with a graph database

#38

Post by pantaloony »

wenc wrote: post #36
pantaloony wrote: post #34

Earlier quoted context omitted.

GraphQL isn’t particularly “graphy” nor does it have much to do (necessarily) with graph databases. Its name is, for the reason that it continually generates that sort of confusion, pretty bad.

You're correct -- it's more of a query-language-ish alternative to REST. However, it does let one work with hierarchical data structures that map more closely to the JSONish mental model that most app developers have, rather than with pure SQL tabular data structures which have to be object-mapped. I'd imagine most developers just want that, rather than capabilities for doing relationship/connection queries which rea…

Right—HierarchyQL or NestQL would be a better name, even. I’m not aware of its being much more ergonomic or helpful for graph queries than SQL is. Certainly nothing like Cypher or another actual query language for graphs. Doesn’t mean it’s bad, it just has a misleading name (in fact TFA even seems a bit confused about what it is)

Re: Build your next app with a graph database

#39

Post by it »

madrox wrote: post #31
the_duke wrote: post #25

I'm currently on my first project involving a graph database . Dgraph coincidentally, and I somewhat like the product. But this is a horrible article that would immediately leave a bad taste in my mouth if I were researching the product. It boils down to a shallow dismissal of relational databases that does not have much more substance than "Relational dbs are old and bad! Graphs are awesome because relations and que…

I'm pleased to hear so many comments saying this. I don't think this style of writing is appropriate for engineering. This is computer science , and even in marketing posts like this one we should be reading analysis of performance benchmarks along with pros and cons. I'm immediately skeptical of technology that takes this marketing approach.

He did show concrete examples of how relational DBMSs force you to model and query in an unintuitive way.

Re: Build your next app with a graph database

#40

Post by FpUser »

I have nothing against graph database concept. I used it myself in some server applications. But reading this article:

>"Relational databases: a software engineering fail"

I would tell this to the author: it is a bad marketing strategy trying to diminish competitor. Don't worry about relational databases. With the comment like in the quote it is clear that you are either incompetent or spreading BS on purpose. Not all of your audience are single cell organisms and they are perfectly able to judge claims on merits rather than propaganda.

Post reply on HN