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

Genealogy of Relational Database Management Systems [pdf]

hpi.de

Post reply on HN
Print view View original

11–20 of 25 posts

Re: Genealogy of Relational Database Management Systems [pdf]

#11

Post by ubermonkey »

SonOfLilit wrote: post #9
ginko wrote: post #4

Earlier quoted context omitted.

I've only had contact with DBs during my university years so please bear with me, but at least to me (mostly a systems programmer who played around with functional and logic programming languages) SQL seems, I dunno.. very crude? For instance it seems to me that PROLOG is a lot better at querying/defining relational facts. Also every time I looked into SQL DBs I felt uncomfortable having to patch together SQL queries…

Few people, when they say "SQL is amazing!", mean the language. The language is ok minus, it's usable and isn't a problem center. String parsing isn't expensive enough for anyone to replace, and there are many benefits to the 100% language decoupling it ensures. What we mean is "RDBMSs are amazing!", and they are. Humanity has spent a lot of resources on their design and evolution, making them into systems that effic…

Yes, that's exactly what I meant.

Re: Genealogy of Relational Database Management Systems [pdf]

#14

Post by Zababa »

ubermonkey wrote: post #3
arjunrc wrote: post #2

This is incredible to see all in one place. I’m preaching SQL to my Org. and it’s only getting preachier over the years, as I see new technologies come and go (OLAP, NoSQL and it’s many variations including Hadoop, Azure Cosmos DB). For an Org. of our size, I’m not sure if these new fads make it any easier. Even if they helped with data streaming, we still are having to move it to a SQL warehouse where we can combine…

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.

Re: Genealogy of Relational Database Management Systems [pdf]

#17

Post by grafs50 »

ubermonkey wrote: post #3
arjunrc wrote: post #2

This is incredible to see all in one place. I’m preaching SQL to my Org. and it’s only getting preachier over the years, as I see new technologies come and go (OLAP, NoSQL and it’s many variations including Hadoop, Azure Cosmos DB). For an Org. of our size, I’m not sure if these new fads make it any easier. Even if they helped with data streaming, we still are having to move it to a SQL warehouse where we can combine…

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?

I'd love to have the ability to write a direct query plan, for the rare occasion where the query planner does something stupid. But, ya SQL is great for the majority of situations.

Re: Genealogy of Relational Database Management Systems [pdf]

#18

Post by bob1029 »

arjunrc wrote: post #2

This is incredible to see all in one place. I’m preaching SQL to my Org. and it’s only getting preachier over the years, as I see new technologies come and go (OLAP, NoSQL and it’s many variations including Hadoop, Azure Cosmos DB). For an Org. of our size, I’m not sure if these new fads make it any easier. Even if they helped with data streaming, we still are having to move it to a SQL warehouse where we can combine…

> I’m preaching SQL to my Org. and it’s only getting preachier over the years

We are all-in on using SQL (SQLite) for our business logic these days. It's wonderful being able to watch the business build most of our customer experiences for us. No more lost-in-translation bullshit exercises between the biz and the tech. Our developers are now mostly tending to the SQL matrix that everyone else works inside of every day. Most of my support issues are along the axis of "Why isnt customer property X showing up in table Y under circumstances Z". We have built a lot of custom tooling so we can quickly answer this question with confidence. 9/10 times the resolution is 1 line in a mapper that needs to be updated somewhere.

For me, SQL only works if the schema is clean and the business can understand why it is constructed in the way that it is. If you were to dump your SQL schema to excel sheets and email it to your project manager, would they have a clue how to piece these things back together or why things are represented the way they are? A well-normalized schema should be intuitive to join together by even non-domain experts. Simply being consistent with naming throughout is 80% of this battle in my mind. When someone says the word "Customer" in context of your SQL schema, everyone on the team should implicitly be on the same page regarding properties and relations around this type.

Re: Genealogy of Relational Database Management Systems [pdf]

#19

Post by funcDropShadow »

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.

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. But this is not the system for which they determined that it is simple.

But even for simple use cases durability might be a requirement. And that is not so simple to get right.

Post reply on HN