4 ms·

> You see, relational databases aren’t dinosaurs. They aren’t lumbering prehistoric relics doomed to extinction by a changing world. They are sharks. Apex preda

> You see, relational databases aren’t dinosaurs. They aren’t lumbering prehistoric relics doomed to extinction by a changing world. They are sharks. Apex predators honed by millions of years of evolution into a perfectly adapted creature that is just as effective today as it was eons ago. RDBM is optimized for file size; it is very much an artifact of its time, when hard drive space was limited. I don't buy it for a second. People think in dictionaries, so just use one. If you are making a simple app and don't need transactions, aggregations, or multiple connections, then just use JSON in an S3 bucket or something. If you are going a step farther, JSON-based databases are quite feature complete these days. For monolithic business logic applications, relational databases are the right tool IMO, but they are used for every use case when they are absolutely not needed. Controversial claim: Joins are a foot gun. It is so easy to make too many tables and mis-use unnecessarily complex table structures because it feels safe and "engineery" to do it. I don't know how many young startups I've seen that absolutely struggle with RDBM performance, and almost always they have gotten themselves into some horrible situation joining five tables deep with a spaghetti ERD and no clear pathway forward. It is hard to make the same mistakes with a JSON foundation.

DeathArrow 4y ago
If the data is highly relational, no JSON structure and data duplication will save you from joins. You will either do them at database level or in memory. I see a need for relational databases, NoSQL, data lakes and all other storage strategies. You chose based on the type of data, the way you acquire it, the way you process and deliver it, based on security and reliability needs. In many non trivial application there is more than one data storage solution implied. Since I work with large microservice based apps, it's a long time since I have to use more than one data storage strategy in the same app.
- engineeringwoke 4y ago
  Agreed on all points. I still think RDBM is over-used; it's the default in many shops for any minor micro-service. It's like using a 20-piece multi-tool for something that only needs a regular kitchen knife.

DeathArrow 4y ago

If the data is highly relational, no JSON structure and data duplication will save you from joins. You will either do them at database level or in memory. I see a need for relational databases, NoSQL, data lakes and all other storage strategies. You chose based on the type of data, the way you acquire it, the way you process and deliver it, based on security and reliability needs. In many non trivial application there is more than one data storage solution implied. Since I work with large microservice based apps, it's a long time since I have to use more than one data storage strategy in the same app.

engineeringwoke 4y ago
Agreed on all points. I still think RDBM is over-used; it's the default in many shops for any minor micro-service. It's like using a 20-piece multi-tool for something that only needs a regular kitchen knife.