4 ms·
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'
by 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 agoDoes 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 agoRemember, 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 agoFair enough!