I ran into a problem on the project I'm working on right now. It is basically an app that stores a path based on GPS coordinates. The app runs on android an saves the GPS location every second and then sends it to on API. I think if I insert a record for every location saved there will be to many records in the table very fast. For example if I go on a run three times a week for 1 hour there will be 10'800 new records per week, now imagine this with 1000 active users for a year...Anyway so I've come up with an idea, that I've never seen before and I'm therefor not sure it is good:I use a relational database (MySql) to store users (and all other data expect of the recorded paths) and then I have a table users_paths which links users to their recorded paths (obviously), the path itself is stored in a noSql (MongoDB) database in a document like this:_id:3474348347389,waypoints:{  {lat, long},  {lat, long},  ...} I haven't yet implemented it because it feels wrong and a bit like an overkill to me. I have also thought to save the recorded paths as a json-file but I'm not happy with that solution either.What do you think? Is this the way to go or am I completely wrong?
Using a relational and a non-relational database in the same project?
database design;mysql;relational database;mongodb;document databases
For example if I go on a run three times a week for 1 hour there will be 10'800 new records per week, now imagine this with 1000 active users for a year.Well, let's not imagine, but actually estimate the data growth. Imagine each GPS coordinate is stored in two 32-bits variables (largely enough; probably you don't need that much precision.) Three hours per week means 10,800 records, or 675 KB of memory. For one thousand users, we obtain 659.18 MB of data increase per week, or 2.6 GB per month or 33.57 GB per year.Therefore, it will take you sixty years to fill a hard disk of a capacity of 2 TB.Back to your original question, with such small set of data, the choice between RDBMS and non-relational databases really doesn't matter. Pick the one you are familiar with.