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

Comparing Database Types

prisma.io

Post reply on HN
Print view View original

101–110 of 176 posts

Re: Comparing Database Types

#101

Post by imchairmanm »

mrjn wrote: post #100
planck01 wrote: post #84

Earlier quoted context omitted.

I am surprised Dgraph isn't mentioned as an example. It is the most starred graph db on Github, and I think it is the best one in terms of performance and scalability.

(Dgraph author) Particularly embarrassing because I actually know the founders of Prisma ;-). Amazing folks! They even included YugaByte, with only 2.8K GitHub stars. Dgraph crossed 11K GitHub stars and is in the top 10 Graph DBs on DB Engine now -- what would it take for us to be in the article, Søren? Just joking. Nice article! Keep up the good work, guys!

Hey there, I'm responsible for this omission! I've gotten quite a few comments internally and externally so I'll make sure to give Dgraph a mention when I incorporate some of the feedback I've received from this thread. Thanks for the heads up!

Re: Comparing Database Types

#102

Post by victor106 »

Can anyone here point to a resource that gives a comprehensive treatment (use cases, pros and cons etc) of all the types (Nosql, NewSQL, relational, timeseries) of databases being used today?

Re: Comparing Database Types

#103

Post by tacotime »

edmundsauto wrote: post #90
reilly3000 wrote: post #85

Earlier quoted context omitted.

I did a MOOC on relational algebra that made me much more productive in SQL and better appreciate the gravity of what RDBMS really offer. Understanding relational algebra helps demystify the magic or query planners and grok why they both add and reduce latency based on use cases.

Mind sharing the course? Sounds useful.

here is one: https://lagunita.stanford.edu/courses/DB/RA/SelfPaced/about

Re: Comparing Database Types

#104

Post by 616c »

AlphaWeaver wrote: post #2

This article comes from the team at Prisma, who are doing some really cool work building "database schema management and design with code" tools. They're working on a new version of their library right now (Prisma 2) and are regularly giving updates to the community and providing test versions. Most everything they make is open source and really well designed. Would recommend checking it out!

I am curious about Prisma2 because I tried to build a server side API with v1 as a novice to graph systems and it became an unwieldy nightmare. Partially my fault for wanting to do it without the SaaS they provide but trying to build with something complicated and Apollo on the frontend with a skilled FE dev got me so confused I put it off.

Re: Comparing Database Types

#106

Post by FridgeSeal »

mdaniel wrote: post #95
planck01 wrote: post #84

Earlier quoted context omitted.

I am surprised Dgraph isn't mentioned as an example. It is the most starred graph db on Github, and I think it is the best one in terms of performance and scalability.

Strange that they have to have such a non-standard license, when they go out of their way to mention Apache 2 several times: https://github.com/dgraph-io/dgraph/blob/master/LICENSE.md Contrast that with Orient, who also have an Enterprise version, and they just straight-up say "Apache 2, no drama" https://github.com/orientechnologies/orientdb/blob/develop/l... We had an absolutely miserable experience trying to get J…

I believe support for additional query languages is in the roadmap.

Re: Comparing Database Types

#107

Post by dehrmann »

planck01 wrote: post #83
gibsonf1 wrote: post #27

The discussion of graph dbs completely misses the semantic rdf graph approach and how that differs greatly from the property graph (which is discussed). So important is not having to have a custom schema for each application that does not communicate with any other app as opposed to using standard ontologies with relationships and classes that are known and allow interoperability between systems (Linked Data Platform…

Do you know of any successfully semantic RDF graph databases, I guess with OWL support? Because I personally don't. If not, it probably is rightfully too much an academic niche to be discussed in the article.

Does Top Quadrant have anything that does this?

Re: Comparing Database Types

#108

Post by henryfjordan »

lmkg wrote: post #19
danenania wrote: post #10

Earlier quoted context omitted.

“It should be emphasized that graph databases can do all other types of databases (relational, document, key/value, etc.)” Not to knock graph dbs, but isn’t the reverse also true?

One of the key features of graph databases is to select one node, and then recursively 'chase' edges until you find another node matching some criteria. Other database models can have trouble representing chasing an unbounded number of edges. E.g. in the relational model, following an edge to another node is usually represented as a Join operation, and SQL doesn't let you parameterize the number of iterated joins. Th…

You absolutely can use recursive SQL to build a graph in a relational database, I've done it. You make a table with a primary key and some data and then make another table that represents edges between objects in the first table. Then, like you describe, you can use recursive queries (built into Postgres) to query your graph. You end up with an adjacency list which might not be the most efficient way to represent your graph, but it works well enough up to a certain size.

I don't quite get what you mean by "the relational model itself cannot fully represent the graph model". If you can store all the edges of a graph and query them, what can't be done?

Graph Databases, depending on the underlying storage model, can have performance increases over relational databases when the JOINs are what you are interested in. This is because JOINs in SQL are often O(n) or O(log n) (if you index the join) where N is the number of rows in the target table, but following a relationship in a graph might be O(1) if you store an object with pointers to other objects right there. Writes might be more expensive though.

It all comes down to use case

Re: Comparing Database Types

#109

Post by dehrmann »

The column-family databases mentioned (Cassandra, HBase) are both just fancy key-value stores that add semantics for separate tables and cell-level data so you're not rolling it yourself.

Re: Comparing Database Types

#110

Post by Darkphibre »

Pheebau wrote: post #69
taffer wrote: post #64

Earlier quoted context omitted.

The table is the relation. A join is just an operation that combines two relations to a superrelation.

A join in an intersection in relational algebra

Oh, wow.

I've been in the industry for over 20 years. I even worked on SQL Server Analysis Services for 5 years (up to 256-dimensional 'cubes' in the early 2000s)... and I never thought of joins in this way. Granted, MDX was a beast in its own right.

Cue discussion about self-taught vs college educations. I've got advantages being self-driven learner... but I've definitely missed out in some regards.

Post reply on HN