[HN Gopher] Genealogy of Relational Database Management Systems ...
___________________________________________________________________
Genealogy of Relational Database Management Systems [pdf]
Author : theintz
Score : 47 points
Date : 2022-02-03 16:26 UTC (6 hours ago)
(HTM) web link (hpi.de)
(TXT) w3m dump (hpi.de)
| buescher wrote:
| Pretty good. Where would the Oracle Lite products go?
| errcorrectcode wrote:
| R:BASE isn't listed, an important PC relational DBMS.
|
| Postgres / Enterprise DB converges towards compatibility with
| Oracle DBMS.
| tmnstr85 wrote:
| Where does Snowflake go on this map?
| tmnstr85 wrote:
| PS... this map is really cool
| arjunrc wrote:
| 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 it with
| other Org. data to answer business questions. Not sure if anyone
| has built out a fully operational reporting architecture without
| using SQL on HN. Long live SQL!
| errcorrectcode wrote:
| OLAP isn't a technology and it didn't go away. That's an
| approach your and many other orgs have been using for decades
| to do data warehousing. NoSQLs definitely didn't go away.
|
| The need for denormalized data and data warehousing will never
| go away.
| ubermonkey wrote:
| 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?
| grafs50 wrote:
| 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.
| ginko wrote:
| 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 as strings and compile
| them at runtime. Why can't I define a DB schema in my
| compiled programming language and have it produce a typesafe
| query that can execute immediately? I know there's wrappers
| that help you define queries in a typesafe manner, but afaik
| these still generate query strings in the background.
| SonOfLilit wrote:
| 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 efficiently solve
| your hard problems years before you first find out you have
| them.
| ubermonkey wrote:
| Yes, that's exactly what I meant.
| errcorrectcode wrote:
| Prolog isn't a DBMS, it's a functional / logic programming
| language. It doesn't store tables or operate on relational
| algebra.
|
| How would you CRUD data DDL, DQL, DML, DCL, TCL against
| tables (not facts or variables) without SQL? Magic?
|
| And why are you cobbling queries together manually and not
| using an ORM or library? SMH.
| errcorrectcode wrote:
| 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.
| Zababa wrote:
| Key-value stores seem easier to reason about for simple use
| cases.
| bob1029 wrote:
| > 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.
| firstSpeaker wrote:
| FoxPro!
| progre wrote:
| At a workshop at Microsoft a few years ago they proudly told us
| that they at that point only maintained 5 internal forks of SQL
| server, recently down from 8.
___________________________________________________________________
(page generated 2022-02-03 23:02 UTC)