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

41–50 of 176 posts

Re: Comparing Database Types

#41

Post by tabtab »

thunderbong wrote: post #37
tabtab wrote: post #23

I'd like to see "dynamic relational" implemented. It's conceptually very similar to existing RDBMS and can use SQL (with some minor variations for comparing more explicitly). You don't have to throw away your RDBMS experience and start over. And you can incrementally "lock it down" so that you get RDBMS-like protections when projects mature. For example, you may add required-field constraints (non-blank) and type con…

Have you seen RedBean ORM? https://www.redbeanphp.com/index.php

I don't really want an automatically generated static RDBMS, I'd like a dynamic RDBMS. For one, one can use it with any programming language, not just PHP.

Re: Comparing Database Types

#42

Post by tabtab »

asah wrote: post #28
tabtab wrote: post #23

I'd like to see "dynamic relational" implemented. It's conceptually very similar to existing RDBMS and can use SQL (with some minor variations for comparing more explicitly). You don't have to throw away your RDBMS experience and start over. And you can incrementally "lock it down" so that you get RDBMS-like protections when projects mature. For example, you may add required-field constraints (non-blank) and type con…

I've done this (commercially!) with PostgreSQL - just start with a single table, with one JSON field, and as you want performance, integrity, etc, add expression indexes, break out frequently used expressions into columns etc. On large tables, obviously there's a cost for this reorganization but you can partition the data first, and only reorg the most recent data (e.g. range partitioning by time). https://www.google…

It seems to treat "direct" columns different than JSON-ized columns. That bifurcation creates two ways of doing things. Ideally, it should be seamless.

Re: Comparing Database Types

#43

Post by manigandham »

Nican wrote: post #21

I am really tired of articles that talk about the different types of databases. People can make a graph databases act like relational databases, and vice-versa. Computers, in the end, are just a Turing machine. Just pay attention that the query that you are executing is actually doing the optimal solution. I wish more time would be spent talking about the underlying algorithms that the different query languages use t…

The type of database and data model is critical. People trying to make one act like another has led to countless problems.

Everything you said about algorithms and query complexity is part of that foundation, not a replacement for it.

Re: Comparing Database Types

#44

Post by doh »

threeseed wrote: post #39
Nican wrote: post #21

I am really tired of articles that talk about the different types of databases. People can make a graph databases act like relational databases, and vice-versa. Computers, in the end, are just a Turing machine. Just pay attention that the query that you are executing is actually doing the optimal solution. I wish more time would be spent talking about the underlying algorithms that the different query languages use t…

This is non-sensical. Take a highly nested JSON document and try and implement it in a relational database. You would have an O(1) lookup in MongoDB and a O(n) lookup in MySQL. Or good luck traversing a graph structure in MongoDB when you should've used Neo4J. So in order to have a performant database you do need to "pay attention" and ensure that your access patterns suit the database type. Also Web Scale is about a…

Well, not really. It's about how you store the data. For instance all graph data can be stored as hexastore [0] which can be stored literally in any database and you will get similar-ish performance out of them.

Some databases are optimized for certain workflows, so for instance they will store only "pointers" to certain data rather than copying them. In addition their clients obfuscate and abstract the storage layer from user.

But you can really store any data in any database, you just might have to do some extra pre/post-processing and multiple the storage requirements.

[0] http://karras.rutgers.edu/hexastore.pdf

Re: Comparing Database Types

#45

Post by nikolasburk »

sourcepath wrote: post #30

What happened with Prisma being all about graphql?

GraphQL is a really important use case for Prisma. That is using Prisma as the "data layer" on top of your database when implementing a GraphQL server (e.g. using Apollo Server). However, it's not the only use case since you can effectively use it with any application that needs to access a database (e.g. REST or gRPC APIs). We actually wrote a blog post exactly on this topic: https://www.prisma.io/blog/prisma-and-graphql-mfl5y2r7t49c/

You can also find examples for the various use cases here: https://github.com/prisma/prisma-examples/tree/prisma2

Please let me know if that clarifies it or if you have more questions! :)

Re: Comparing Database Types

#46

Post by Nican »

threeseed wrote: post #39
Nican wrote: post #21

I am really tired of articles that talk about the different types of databases. People can make a graph databases act like relational databases, and vice-versa. Computers, in the end, are just a Turing machine. Just pay attention that the query that you are executing is actually doing the optimal solution. I wish more time would be spent talking about the underlying algorithms that the different query languages use t…

This is non-sensical. Take a highly nested JSON document and try and implement it in a relational database. You would have an O(1) lookup in MongoDB and a O(n) lookup in MySQL. Or good luck traversing a graph structure in MongoDB when you should've used Neo4J. So in order to have a performant database you do need to "pay attention" and ensure that your access patterns suit the database type. Also Web Scale is about a…

That is exactly it. Some SQL databases (CockroachDB and Postgres come to mind) can have the option of having O(1) JSON lookup. It just has to implement the correct algorithm, and index the data the correct way.

It is not about the database type. It is about the underlying algorithms and data structures.

Re: Comparing Database Types

#47

Post by taffer »

> Relational databases get their name from the fact that relationships can be defined between tables.

This is a widespread misconception. Relational databases get their name from relations in the mathematical sense[1], i.e. sets of tuples containing facts. The basic idea of the relational model is that logical predicates can be used to query data flexibly without having to change the underlying data structures.

The basic paper by Codd[2] is really worth reading and describes, among other things, the problems of hierarchical and network databases that the relational model is meant to solve.

[1] https://en.wikipedia.org/wiki/Finitary_relation

[2] https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf

Re: Comparing Database Types

#48

Post by nikolasburk »

taffer wrote: post #47

> Relational databases get their name from the fact that relationships can be defined between tables. This is a widespread misconception. Relational databases get their name from relations in the mathematical sense[1], i.e. sets of tuples containing facts. The basic idea of the relational model is that logical predicates can be used to query data flexibly without having to change the underlying data structures. The b…

Thanks for the hint, we'll update the article! :)

Re: Comparing Database Types

#49

Post by Nican »

shostack wrote: post #29
Nican wrote: post #21

I am really tired of articles that talk about the different types of databases. People can make a graph databases act like relational databases, and vice-versa. Computers, in the end, are just a Turing machine. Just pay attention that the query that you are executing is actually doing the optimal solution. I wish more time would be spent talking about the underlying algorithms that the different query languages use t…

Do you have any articles you'd suggest that in your opinion cover the appropriate underlying guts of them?

Unfortunately, this has something that has been on my backburner for a while. I do not know of any articles that fill exactly the need that I am talking about. :(

Re: Comparing Database Types

#50

Post by jorblumesea »

Nican wrote: post #21

I am really tired of articles that talk about the different types of databases. People can make a graph databases act like relational databases, and vice-versa. Computers, in the end, are just a Turing machine. Just pay attention that the query that you are executing is actually doing the optimal solution. I wish more time would be spent talking about the underlying algorithms that the different query languages use t…

> Computers, in the end, are just a Turing machine.

This isn't a helpful abstraction. Electricity is just electrons after all, why think about how you're going to wire your house when it's all just atoms? Read a bunch of books on quantum physics, then become an electrician /s

> Just pay attention that the query that you are executing is actually doing the optimal solution.

Isn't that the entire reason for articles like this? eg: If you have data with large amounts of relations a no-sql database probably isn't the right approach.

> I wish more time would be spent talking about the underlying algorithms that the different query languages use to accomplish the tasks.

Absolutely, if just for knowledge's sake, but these are largely not needed if you understand the high level use cases for any given DB. It's cool if you understand B-Trees but not strictly needed to use sql. In fact, many would this this not helpful.

Post reply on HN