将常规SQL结果数组保存为另一个表中的条目确实会减少查询数量，不管是否有好主意？

Question

I had an idea and I wonder if its completely stupid or a good idea.

I'm working on a web app which analyze GPX tracks and give stats. Actually I'm storing the coordinates of each points of each tracks in a table, this way :

point_id | track_id | lat | lon | else | speed | timestamp

and each time I'm selecting entries from this table, I do it by track_id :

 SELECT * FROM points WHERE 'track_id'=12

And so I'm getting a full array that I then process to get it formatted for example for my map script :

[[46.323, 7.543, 1465663049], [46.323, 7.543, 1465663049], [46.323, 7.543, 1465663049]]...

Or for my speed graph script :

[[1465663049, 9, 12], [1465663049, 9, 12], [1465663049, 9, 12], [1465663049, 9, 12]...

But I think that making a query involving hundreds of entries to process them the same way every time is a bit unproductive so I was wondering if I could make a kind of buffer table with my processed results, for example :

track_id | map_array | graph_array 

So I would only have to make one query to get my array, but it means that the field will be quite big as they would need to store thousands of characters an entry.

Maybe a best choice would be to store them in a json datatype field so it can be easily used by my scripts ?

Do you think it is a good idea ?

TL;DR : Storing gps tracks point in several entries or storing them in a single entry with json datatype ?

Thank you for reading me.

François

Answer 1

Thanks to Solarflare advices and some reflexion I think I have the answer for my own case.

As my queries for tracks will be always identical, it makes no sense to look trough each points it's like always asking the same question when you know the answer.

So here is my database structure I will be using and which I think is the most easy to use and maintain but also the less resource intensive. At least in my own case.

• The gpx files will be decomposed in points that will be stored in the database to be able to have access to the original data.
• In another table, the points will be stored as an array in a text field for quick and simple "one query" access.

My two tables will be something like that :

Original track points :

point_id | user_id | track_id | lat | lon | else | speed | timestamp

Processed tracks :

track_id | user_id | map_array | graph_array 

I'm not a php or database expert but if I have to query 10 tracks on a page the performance should be different if I have to get 10 * ~600 entries or just 10 entries which doesn't need processing.