First, I don't consider that immutable. Second, that isn't true for all databases, often you have to set it up and turn it on, and think about what you're doing as there are considerations for storage and backups. Third, it isn't like you can just get the data back magically and without effort. It can be a problem to hunt through. It can be an enormous amount of data.
There are also also many use cases where you don't want to "store" something at all, just compute the value (eg: a shopping cart that is not yet a purchase), and you don't want to to either 1. duplicate implementations or 2. wait for a network request to your database to complete.
Store it in memory? I doubt the amount of data they provided for a test problem was so tremendous that it required a database.
In itself this is a good (dis)qualifier; if I give someone a problem and tell them the data will never exceed 10k rows, I expect them to be practical and not waste time setting up a database.
If one is only ever going to append to a database and never read it or use data in it, then one does not even need to store the data being appended, let alone need a database. However, since the use case here appears to be storing GPS data, it would be reasonable to conclude that data is being actively consumed.
What? while sure you might not need a database if you have under 10k rows, if you want any amount of resiliency storing data in memory is a huge mistake as if the current instance of the application fails your done for.
Given that really the only thing a computer can do is store, manipulate and present data, what else would make sense to store that data? Aren't RAM and hard drives pretty much databases?
Do you ever check the underlying data when you write a database query? Same logic applies here. There’s limits to what you can do but don’t let perfect be the enemy of good.
reply