4 ms·

>You have no clue what SQL or ACIDity is. That's quite an attack. I trained for an Expert SQL certification from Microsoft back then, when I was writing 3000K+

• rantanplan 10y ago
  If you have a clue, as you say, and still believe that it's a good idea to store critical data with NoSQL then I don't know what to say. Obviously you don't care enough that almost every NoSQL solution out there has been found to make false claims about their guarantees. The billions that have been sunk in the blackhole that's called NoSQL in the last decade is unprecedented. You don't have to change my mind. I have(and still use) both. And I still maintain that people who use NoSQL for 99% of their projects are making the wrong choice.
  • brianwawok 10y ago
    So I think a lot of people agree with you on > Many people choose the wrong tool for the job I think that is far past database choice. I think many people build SPAs that end up hurting the product over a traditional setup. I think many people use microservices where a monolith would have much better performance and reliability. As for the basic premise > that people who use NoSQL for 99% of their projects are making the wrong choice. Is perhaps kinda right? Some people may really only touch giant data sets. So for them always using NOSQL is smart. The people that write webapps with 12 users? More questionable. Most cases you can decide if you need to leave RBMS with something like. 1) Do you need to store in the next year > 100GB of data that you need to access in realtime? 2) Do you need in the next year to store > 1TB of data that you need to access in semi-realtime? 3) Do you need in the next year to handle > 1000 writes per second? 4) Do you need in the next year to handle > 1000 reads per second? Not a perfect guide, and I am sure you can think of edge cases that can still be dealt with in a RDBMS.. but it is a decent starting place. One tricky part is that if you are optimistic, almost any app can check off #3 or #4 (Like Uber but for Baby Strollers). Knowing how to realistically estimate demand for a possibly viral startup is hard.
    • rantanplan 10y ago
      The above is good as a rule of thumb indeed. Another one that I'd add is: - "Are the records in each table in the hundred of millions? Then most probably you'll do fine with an RDBMS". If you go above that, or you have operations that will extrapolate that number in the billions then you can offload them into whatever non-RDBMS storage you want and do your thing. But that's the thing with RDBMS, you can always move(or offload part of) your data to a non-RDBMS solution afterwards. But doing the inverse? I wouldn't want to be in that person's shoes ;)
      • brianwawok 10y ago
        Does row count matter that much compared to data size? I.e. if I have a billion rows but they are 2 32-bit ints, that isn't a lot of data (2 GB + index). I guess the index starts to get pretty big.. but I always just think of raw data size vs # of rows.
        • rantanplan 10y ago
          Remember, it's just a rule of thumb. Now... tables with 2 32-bit ints as columns are not exactly typical RDBMS data. Also, data in RDBMS are... well relational :) Meaning, the rows of just one table are not that important. The data are going to be queried and combined with data from other tables. And I know that typical relational data that consist of hundreds of millions of entries in each table is something that most DBs can handle. Again, rule of thumb :D
          • brianwawok 10y ago
            Fair enough!
• orf 10y ago
  > 3000K+ long stored procedures You wrote a 3,000,000 lines long stored procedure in Access? That's ridiculous and it's hardly a testament to "how much you know about RDBMS".
  • r2dnb 10y ago
    Wow, I meant 3K thanks for pointing this out ;) And I didn't wrote the Access application, I was migrating it.