4 ms·

>because of the one thing it does well. This "one thing it does well" business is then presented as : "using the right tool for the right job" and it's difficu

by r2dnb 10y ago

>because of the one thing it does well. This "one thing it does well" business is then presented as : "using the right tool for the right job" and it's difficult to argue against that because the counterpart can easily deride you as a fanatic of some technology, someone not objective enough, etc... It is however interesting that we used relational databases for virtually everything for decades even though SQL is suboptimal at most things if we take them in isolation. Some will argue that people are now realizing their mistake, but the truth is these companies were successful and we were all getting our paychecks. (PS: I choose to use NoSQL for virtually all my projects) The real driver shouldn't be the one thing it does well. Many times - if not most of the time - it's preferable to use a tool optimal for the most important parts and suboptimal for the rest. I personally prefer to provision two more instances, than to add two more technology stacks.

rantanplan 10y ago
> It is however interesting that we used relational databases for virtually everything for decades even though SQL is suboptimal at most things You have no clue what SQL or ACIDity is. For 99% of the cases SQL/RDBMS is the right choice. You probably think you belong in that 1%, but from your comment, I suspect you do not. > I choose to use NoSQL for virtually all my projects That's because you have no important data to store. When you get to store data that are important to your customers you're gonna have a big revelation.
- anonx 10y ago
  >> You have no clue what SQL or ACIDity is. "NOSQL" doesn't mean "no ACID". There are plenty of NOSQL DBs that are ACID compliant. And SQL is not the only way to write your queries. There are a lot more QLs.
  - rantanplan 10y ago
    Even though what you say it's true, my comment is still correct and relevant to the OP. Also, of the NoSQL DBs that support ACID, I wouldn't touch them for any serious work or primary data at least. None of them are battle-tested in the same way Postgres is for example. And again, people who really need these type of DBs fall into the 1%, and I'm being very generous.
- brianwawok 10y ago
  Why do you think NoSQL means not important data? MongoDB eats data but I am not sure every NoSQL database does. NoSQL does add certain kinds of complexity, but also simplifies certain problems. Depends where your hard problems are..
  - rantanplan 10y ago
    Because in the 2 decades I'm in the industry I see RDBMS make the world spin and NoSQL DBs destroying companies and families. MongoDB and CouchDB eat data for breakfast, I know that from 1st hand experience. And all the others DBs that claim that do not keep cropping up in Aphyr's blog. I ain't saying that all NoSQL dbs are useless. I'm just saying that proposing and choosing an RDBMS solution is going to be the right choice for 99% of the projects. Yes, most people think that they belong in that 1% where they have the infrastructure problems and big data of Google, FB and Twitter but.... they don't.
    - threeseed 10y ago
      In the last 2 decades in the industry as well I've never lost data with MongoDB, Riak or Cassandra but have with Oracle, DB2 and PostgreSQL. After all databases are just software and there will always be bugs. Some people just get tripped up by different ones. And you are woefully ignorant to think the RDBMS is the right choice for 99% of projects. Especially since you think that the 1% of remaining users are purely worried about scalability. Hint: think about the schema problems associated with storing auto generated features from deep learning models.
      - rantanplan 10y ago
        >In the last 2 decades in the industry as well I've never lost data with MongoDB, Riak or Cassandra but have with Oracle, DB2 and PostgreSQL Yet every test proves otherwise. Also, use Google to see how people have lost data with MongoDB. Mongo is not considered a serious piece of technology by any scientist or engineer I know. Postgres though is universally considered an engineering marvel. >Hint: think about the schema problems associated with storing auto generated features from deep learning models. Hint: The problem you mentioned? Even less than 1% Calling me ignorant doesn't change reality you know.
- r2dnb 10y ago
  >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+ long stored procedures to migrate an Access application at a fortune 40 company. So I know what it is and I know quite a good deal about RDBMS. I'm not among those who criticize what they don't know. Regarding the gist of your comment on NoSQL, I haven't been able to convince people coming from where you are with two days of meetings in a row, so I'm fairly confident I'm not going to change your mind on HN.
  - 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.

by r2dnb 10y ago

rantanplan 10y ago

> It is however interesting that we used relational databases for virtually everything for decades even though SQL is suboptimal at most things You have no clue what SQL or ACIDity is. For 99% of the cases SQL/RDBMS is the right choice. You probably think you belong in that 1%, but from your comment, I suspect you do not. > I choose to use NoSQL for virtually all my projects That's because you have no important data to store. When you get to store data that are important to your customers you're gonna have a big revelation.

anonx 10y ago
>> You have no clue what SQL or ACIDity is. "NOSQL" doesn't mean "no ACID". There are plenty of NOSQL DBs that are ACID compliant. And SQL is not the only way to write your queries. There are a lot more QLs.
- rantanplan 10y ago
  Even though what you say it's true, my comment is still correct and relevant to the OP. Also, of the NoSQL DBs that support ACID, I wouldn't touch them for any serious work or primary data at least. None of them are battle-tested in the same way Postgres is for example. And again, people who really need these type of DBs fall into the 1%, and I'm being very generous.
brianwawok 10y ago
Why do you think NoSQL means not important data? MongoDB eats data but I am not sure every NoSQL database does. NoSQL does add certain kinds of complexity, but also simplifies certain problems. Depends where your hard problems are..
- rantanplan 10y ago
  Because in the 2 decades I'm in the industry I see RDBMS make the world spin and NoSQL DBs destroying companies and families. MongoDB and CouchDB eat data for breakfast, I know that from 1st hand experience. And all the others DBs that claim that do not keep cropping up in Aphyr's blog. I ain't saying that all NoSQL dbs are useless. I'm just saying that proposing and choosing an RDBMS solution is going to be the right choice for 99% of the projects. Yes, most people think that they belong in that 1% where they have the infrastructure problems and big data of Google, FB and Twitter but.... they don't.
  - threeseed 10y ago
    In the last 2 decades in the industry as well I've never lost data with MongoDB, Riak or Cassandra but have with Oracle, DB2 and PostgreSQL. After all databases are just software and there will always be bugs. Some people just get tripped up by different ones. And you are woefully ignorant to think the RDBMS is the right choice for 99% of projects. Especially since you think that the 1% of remaining users are purely worried about scalability. Hint: think about the schema problems associated with storing auto generated features from deep learning models.
    - rantanplan 10y ago
      >In the last 2 decades in the industry as well I've never lost data with MongoDB, Riak or Cassandra but have with Oracle, DB2 and PostgreSQL Yet every test proves otherwise. Also, use Google to see how people have lost data with MongoDB. Mongo is not considered a serious piece of technology by any scientist or engineer I know. Postgres though is universally considered an engineering marvel. >Hint: think about the schema problems associated with storing auto generated features from deep learning models. Hint: The problem you mentioned? Even less than 1% Calling me ignorant doesn't change reality you know.
r2dnb 10y ago
>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+ long stored procedures to migrate an Access application at a fortune 40 company. So I know what it is and I know quite a good deal about RDBMS. I'm not among those who criticize what they don't know. Regarding the gist of your comment on NoSQL, I haven't been able to convince people coming from where you are with two days of meetings in a row, so I'm fairly confident I'm not going to change your mind on HN.
- 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.