5 ms·

Why would a team decide to use nosql to manage "a few hundred" entities? Nosql databases excel at simple lookups and gets by ID, rather than trying to sort and

• winrid 4y ago
  NoSQL might not be the right term here. Maybe you mean "columnar databases"? Ex Mongo sorts just fine, and can optimize sorting with indexes.
• lmm 4y ago
  Why would you ever use SQL? The SQL transaction model doesn't make a lot of sense for most use cases (including essentially anything that uses the internet), and trivial usability things like being able to have collection columns without having to define a separate table all add up.
  • akhmatova 4y ago
    That must have been what they were thinking when they made the decision to go with Cassandra.
    • lmm 4y ago
      I'm working on a system that's using Cassandra on a small scale (like, probably less than a million entities) now, it's great. Haven't had any consistency issues because we've designed our data flow properly (SQL will help you paper over a bad data flow for longer but that's a double-edged sword), and getting true just-works HA (master-master where a failover doesn't interrupt your writes) out of the box is a huge advantage over something like Postgres.
      • akhmatova 4y ago
        Oh, I don't dispute that there are valid use cases. But the above instance sounds like a variant of the "because, bwah, SQL is hard" line of thought that seems to have powered much of the (now historical) NoSQL boom.
  • cutler 4y ago
    > SQL transaction model doesn't make a lot of sense .... anything that uses the internet So decades of PHP+MySQL and Rails+PostgreSQL were simply misguided?
    • lmm 4y ago
      > So decades of PHP+MySQL and Rails+PostgreSQL were simply misguided? To the extent that transactions were the point, yes (though there may not have been many alternatvies for a datastore to use when Rails was getting started). In the case of PHP+MySQL of course MySQL transactions were disabled by default in that era (up until 2010 in fact).
      • housecarpenter 4y ago
        I'd be interested to hear why you think this, or if you can link to something that explains this perspective.
        • lmm 4y ago
          There's a fundamental mismatch between the HTTP request-response model and the SQL "open transaction" model - you can't open a transaction, serve a form, and wait for a user to submit it and commit that in the same transaction, because what if the user walks away? But if a transaction doesn't extend to the actual user action then it's basically useless; you can't do transactional read-modify-write when the one doing the modifying is the user. After all, what do you do when a transaction fails? Most webapps either retry or fail (if they even bother to handle that case at all), but you don't need transactions to do either of those. In an actual database application you can tell the user their transaction didn't commit and ask them to deal with it, but again you can't really do that over the HTTP request/response cycle (because what if the user submits the form and walks away? They expect their input to be saved, whatever happens on your backend).
          • hnfong 4y ago
            What is the alternative? Use distributed databases that don't guarantee atomicity at all, and write up complicated solutions to work around it? Or are there some non-transactional, atomic databases that more nicely fit the web model that I don't know about?
  • yCombLinks 4y ago
    That's roughly the same argument as choosing a strongly typed vs a weakly typed language. I much prefer the strong typing personally. Yes, it's more work up front. But every other person that works with the data knows what they're getting.
• nkuttler 4y ago
  Resume driven design
• maccard 4y ago
  At a few hundred entities, it doesn't really matter what tech you choose, so you should probably choose whatever is closest to hand.