Can we agree, a lot of people tend to pick the wrong one for the job at hand.

And just in case devRant does it's magic on the image....

Full image

  • 12
    Excel is missing though. SCNR ^^
  • 7
    @Fast-Nop so is MsAccess, not that I count either as a DB you should/would want to use.
  • 2
    Firestore, not mongoDB?
  • 1
    Unless you’re locked into aws, then you use aurora. 😑
  • 10
    One big CSV stored on a USB flash drive.
  • 2
  • 0
  • 0
    What this cloud database propaganda?

    Joke aside, can you blame them? Where I'm from, college courses mostly cover relational databases (mysql, postgres, sqlite), barely touching on nosql as a concept.

    Most legacy projects use these relational databases so management wants more of those. They don't care which database they end up marrying with as long as it works and is relatively known.
  • 2
    @kwilliams ntfs/exfat formatted of course, so it can go beyond 2gb file limit
  • 0
    @mabbott94 For their exorbitant tuition fees they might as well!

    But that's not my point.

    Engineers come out of college barely knowing basic sql on relational databases.
    They get their first job.
    When given the choice, go for a relational dbms because angry client does not want to feel like you're just now learning your tools.
    Next guy has to maintain it, still a relational database.
    More experienced guy wants to migrate to a better solution, client does not see the upside of it (it works fine already).

    Fast forward a decade or so and most systems that don't come out of a start-up are made with relational databases and outdated tools.
  • 0
  • 1
    There's a few notes I'd add:

    1. You should almost always start with SQL, because it has the most features for keeping your data consistent and healthy. Both memory & document stores are great as faster denormalization layers in front of it. A simple API with little backend logic can be served directly from a document store though.

    2. Bigquery is arguably SQL, not NoSQL. It's main purpose is storing events and flattened data for business intelligence though, so it's not a generic main database.

    3. Graph and Timeseries databases are missing. You rarely use them as primaries though.

    4. Graph databases can be amazing for modeling hierarchies and networks of entities. Not just social networks, but also supply chains and delivery networks, labor substitution rosters, etc. You can however do graph query optimization using a hexastore pattern fully on Redis.

    5. Timeseries are amazing for anything that should be displayed as a time-based plot. Can also be done in Redis.
Add Comment