Genealogy of Relational Database Management Systems [pdf] • Hacker News Board

Re: Genealogy of Relational Database Management Systems [pdf]

#21

Post by Zababa » Fri, Feb 04, 2022, 5:05 PM UTC

funcDropShadow wrote: post #19

Zababa wrote: post #14

Earlier quoted context omitted.

Key-value stores seem easier to reason about for simple use cases.

You are absolutely right! They seam easier to reason about. But relational databases actually are simpler to reason about when you compare equivalent feature sets. I've seen people argue it is just a key value store, so it is dead simple, right? But then they didn't just use key value store features. They used or implemented themselves joins, transactions, consistency constraints under parallel modifications, etc. Bu…

You're right too, it's hard to know from the start what you will need, and your needs will often grow to the point that you'll need a full relational database.

Re: Genealogy of Relational Database Management Systems [pdf]

#22

Post by alexvoda » Fri, Feb 04, 2022, 5:06 PM UTC

errcorrectcode wrote: post #5

R:BASE isn't listed, an important PC relational DBMS. Postgres / Enterprise DB converges towards compatibility with Oracle DBMS.

Percona is also missing.

Unlike other such maps this map is a bit form over function. There are various crossings up or down that are there only to make it more visually interesting (more like a city metro map) but harder to follow.

Re: Genealogy of Relational Database Management Systems [pdf]

#23

Post by CRConrad » Sat, Feb 05, 2022, 3:31 PM UTC

errcorrectcode wrote: post #6

ubermonkey wrote: post #3

Earlier quoted context omitted.

I'm kind of amazed that SQL needs to be preached about. It works really well! Just pick whatever flavor works best for your org and go forward. What would you use INSTEAD of SQL?

Some people think maintaining bank accounts on Mongo would be a good idea. ACID, locking, referential integrity, SQL (language flavors and RE DBMSes) aren't appreciated, probably due to a lack of CS education.

Some people think putting actual money on blockchain is a good idea.

Dunno Mongo, but perhaps even that is better than having it shredded.

Re: Genealogy of Relational Database Management Systems [pdf]

#24

Post by CRConrad » Sat, Feb 05, 2022, 3:43 PM UTC

Zababa wrote: post #14

ubermonkey wrote: post #3

Earlier quoted context omitted.

I'm kind of amazed that SQL needs to be preached about. It works really well! Just pick whatever flavor works best for your org and go forward. What would you use INSTEAD of SQL?

Key-value stores seem easier to reason about for simple use cases.

AIUI, you can have a key-value store is an SQL RDBMS: Just make a big bunch of two-column -- key and value -- tables.

Also, again AIUI, you can build an RDBMS on top of a key-value store: "Just" build a whole lot of key-value pairs where the "value" is a reference to another key more often than not. (Perhaps not just for actual references to other related tables -- or what would be another table in a real RDBMS -- but for each separate key-value store that would just be another column in a real RDBMS. Then I suppose your primary ("key column") key-value pair would have a lot of rows for each key; one for each "column"?)

I suspect most real-world usage of key-value stores in one fashion or another approaches the above... And then the vaunted "simplicity" has gone out the window (and made SPLAT! on the ground far below).

But by then you're so [invested in | married to | sunk cost-fallacied with] your key-value store that changing to a real RDBMS is nigh impossible.

So better start with a real RDBMS from the beginning.

Re: Genealogy of Relational Database Management Systems [pdf]

#25

Post by CRConrad » Sat, Feb 05, 2022, 3:46 PM UTC

They make it look like Interbase ended with the open-sourcing of Firebird. In reality that turned out to be a fork; Interbase itself is still available from Embarcadero.

Makes one a bit suspicious about how accurate it is in other corners I know less about.